If it's any help, I attached a small DoS-like app which periodically bombards InSim with IS_BTNs at a given interval (in milliseconds). I didn't manage to trigger any problems with this, perhaps you'll have better luck?

EDIT: File removed, see this post.

Quote from MadCatX :

If it's any help, I attached a small DoS-like app which periodically bombards InSim with IS_BTNs at a given interval (in milliseconds). I didn't manage to trigger any problems with this, perhaps you'll have better luck?

This also replicates the exact same issue

OK, looks like there must be some difference between the setup of MadCatX and PoVo's tests.

The only relevant questions I can think of at the moment are :

1) What operating system(s) are you using?

2) Where are the host, guest and the InSim program running? All on the same LAN or the same computer, or are some of them remote?

EDIT :

3) How many buttons are you sending and at what interval? The buffer goes up to 8K so if you send more than that all at once, it is expected to lose connection. Though this is supposed to be safer than the old system in all cases.

4) What error messages are you getting? For example any WOULDBLOCK messages?

Using MadCat's ButtonBomb, I got a client disconnect every time I've tried so far, except for a local server + client + InSim. Considering the amount of data being sent (over 54KB of button text alone) I'm not really surprised.

Client & InSim: Windows 7 64bit
Servers tested:
Windows Vista 32bit (LAN) - lost connection
Wine on Ubuntu 10.04 (LAN) - lost connection
Windows 7 64bit (local) - connection OK

Server log:

Interestingly, when testing with localhost, the buttons didn't get displayed on screen if the client was already on the server when the InSim connected. When the client joined with InSim already running, the buttons displayed fine, but the text in the chat history went missing - probably to do with the many overlaid buttons.
On the LAN servers, the buttons caused a disconnect whichever connected first.



I'll try do some more tests later with my own test app, hopefully with some more OS & network combinations as well as different numbers of buttons etc.


BTW MadCatX, the "Packet count" option in the ButtonBomb is never used in your code, so it sends out 238 buttons every time.

I've activated cheat protection on B9, via the master server so no installation is needed.

It's better researched and more extensive than the cheat protection currently on 0.6B.

So, if you know of constants that can be changed to make you go faster and not get kicked, you are welcome to give it a go on B9.

I've set it to only kick and not ban you for now, so you can feel free to test.

Let's not discuss which values to go for. This request is only for people who already know how to do it.

[ EDIT : If you tested before this edit, you would have not been CPW kicked - my mistake - it should work now ]

Quote from Scawen :

OK, looks like there must be some difference between the setup of MadCatX and PoVo's tests.

The only relevant questions I can think of at the moment are :

1) What operating system(s) are you using?

2) Where are the host, guest and the InSim program running? All on the same LAN or the same computer, or are some of them remote?

EDIT :

3) How many buttons are you sending and at what interval? The buffer goes up to 8K so if you send more than that all at once, it is expected to lose connection. Though this is supposed to be safer than the old system in all cases.

4) What error messages are you getting? For example any WOULDBLOCK messages?

1) The LFS server runs on Windows Server 2008.

2) The LFS server runs remotely from a dedicated server. The InSim system and LFS client from my own computer.

3) All the buttons that I posted earlier are sent at once with no interval in between them.

4)

Quote from PoVo :

The guest loses the connection.

[ ... 64 BUTTONS ... ]

Here is an output of the buttons sent.

Once they are sent, I lose connection 8/10 times. Try the same in 0.6B and it never happens

P.S: Don't mind the ClickID, the list was built before sending the buttons and the buttons are assigned ClickID's afterwards.

Just a little maths here.

It should be possible to send up to 8K in a burst, though that is right on the limit and doesn't allow for any game packets, so it would be safer to aim a bit lower than 8K.

Now, as you've sent 64 buttons, this should be fine if the average button size is less than 128 bytes (8192 / 64 = 128). Your buttons look a lot smaller than that. But... are the button packets constructed properly? I mean, using the smallest packet size that can contain the text you are sending? If, for example, the packets are built in a "quick hack" sort of way, using the full allowed size of 252 bytes (but filled mainly with zeros) then that is a simple explanation of why the guest would disconnect.

I'm very interested to know if that is the cause.

I suppose I could code LFS to automatically compact buttons that you send, to reduce bandwidth. Or I could increase the buffer size. I didn't give much serious consideration to the buffer size until now. I just thought "8000 bytes is loads of text for anyone's screen and that will be fine". But maybe I am wrong about that, considering that every button has a 12 byte header before the text...

Quote from Degats :

Interestingly, when testing with localhost, the buttons didn't get displayed on screen if the client was already on the server when the InSim connected. When the client joined with InSim already running, the buttons displayed fine, but the text in the chat history went missing - probably to do with the many overlaid buttons.
On the LAN servers, the buttons caused a disconnect whichever connected first.

This is consistent with my findings. I also tried to bomb a WINE server running on a native Linux machine from virtualized Windows 7 box running on the same metal. This also didn't trigger any disconnections so it looks like the problem is only if the host and InSim app run on different machines?

Quote from Degats :

BTW MadCatX, the "Packet count" option in the ButtonBomb is never used in your code, so it sends out 238 buttons every time.

This sounds like my kind of mistake :doh: Anyway, I uploaded a somewhat improved version. It allows you set delays between each packet and between each "salvo". Both delays can be set to 0 for constant packet shower. (feel free to modify and reupload the app)

Quote from MadCatX :

This also didn't trigger any disconnections so it looks like the problem is only if the host and InSim app run on different machines?

Yeah, that's what I figured - I doubt the OS will be a significant factor. It's probably down to local connections usually having vastly lower latency, so the buffer is being emptied much faster. So fast, it never actually gets full. It also means that internet clients will be susceptible to problems with much fewer buttons than on a LAN.

I know this is going to sound insane, but a 64KiB buffer for InSim connections should be OK for the foreseeable future.

Quote from cargame.nl :

...it would be nice if it wasn't possible to drive 1 sec under WR anymore with XFG, keyboard and 100% fuel on 0.6B9 TEST.

As I mentioned yesterday, there is cheat protection currently on B9, so it would be great if you could try that again (on any B9 host) so I'll know if it is fixed.

Quote from Dygear :

I know this is going to sound insane, but a 64KiB buffer for InSim connections should be OK for the foreseeable future.

That would allow the maximum number of buttons, sent with the maximum number of characters each, in a single burst, so that seems to make sense. But there isn't any real need for such a big buffer, except to avoid guests geing disconnected. But even with that limit, you could force a disconnection anyway by sending the same outrageous buttons burst twice over. It's an error that could possibly happen due to a bug in an InSim program, no matter what limit we set, and we don't want people disconnected due to a bug in an InSim program. So I'm working on a better solution which is to disallow InSim from overfilling the buffer. After some sensible limit, like 16K or so, InSim will not add any more to the buffer - it will just discard extra buttons. LFS will be able to add another 8K of game packets to that buffer and that should allow for anything. This way, any sensible number of buttons is allowed and it will be very difficult, maybe impossible, to force a guest to disconnect by sending too many InSim buttons.

Great, if you decide to implement this solution, would you consider adding a new InSim packet (IS_OVF?) used by LFS to let InSim app know it overfilled the buffer and it should try to send the rest of the data later? InSim libraries programmers would probably appreciate this a lot.

Quote from Scawen :

As I mentioned yesterday, there is cheat protection currently on B9, so it would be great if you could try that again (on any B9 host) so I'll know if it is fixed..\

I did yesterday on the official B9 host. Although I am not really experienced in this whole cheating thing. But on this particular exploit its looking good.

Did planned an update of the S2 server to boost testing but didn't had enough time this morning to complete a short manual yet... Maybe tonight or tomorrow. Somehow there is also increased activity the last days

.

Quote from MadCatX :

Great, if you decide to implement this solution, would you consider adding a new InSim packet (IS_OVF?) used by LFS to let InSim app know it overfilled the buffer and it should try to send the rest of the data later? InSim libraries programmers would probably appreciate this a lot.

Well... I don't think it is really needed, because the buffer is really quite big now. Have a look at the attached image - this can easily be sent in a single burst. I've increased the number of characters that can be displayed on screen at one time to 8192 (was 4096) so this is now possible. [ EDIT : the buffer size is now 16384 and these buttons only needed 13440 bytes ] The idea is that you can send an entire screen in one burst, and that's why I don't think an overflow warning is necessary.

Quote from cargame.nl :

I did yesterday on the official B9 host. Although I am not really experienced in this whole cheating thing. But on this particular exploit its looking good.

Did planned an update of the S2 server to boost testing but didn't had enough time this morning to complete a short manual yet... Maybe tonight or tomorrow. Somehow there is also increased activity the last days

Thanks - a cargame.nl test would be good, as I do hope to release the official version next week. It might be a good idea to wait until tomorrow for your test, because I should be able to release B10 at some point in the afternoon, and it is definitely safer.

Its good that we can still add AI's in S2 cars on demo server

In connection to working with InSim features, is there any chance to see client's IP via InSim in near future (official patch of this test patch)? In IN_NCN, for example. This would be very useful.

Would be nice but it would also cause a compatibility problem with currently available InSims. Such changes are to big to act on, one week before an official release.

For example the very popular Airio needs a change and I have no idea where Worry is to just name one problem (Last Activity: 13th July 2012 09:58). Now can't that never be a reason to not progress but just one week for finding solutions is not enough.

One tip; you can reliably retrieve username - IP from the log file in this new version. Its not as nice but its a solution.

Quote from cargame.nl :

One tip; you can reliably retrieve username - IP from the log file in this new version. Its not as nice but its a solution.

Wow! Nice, it's so neatly written in that log file now

B10 is now available. See first post.

Improved cheat protection stops some more ways to cheat

Fixes :

Sending too many InSim buttons could cause guests to disconnect
( http://www.lfsforum.net/showthread.php?p=1753675#post1753675 )
It was possible to make an AI driver join with a disallowed car
( http://www.lfsforum.net/showthread.php?t=76140 )
Leaving garage screen could cause problems with a car script
( http://www.lfsforum.net/showthread.php?p=1744592#post1744592 )

http://www.lfsforum.net/showthread.php?p=1754543#post1754543
would be nice if this will be fixed aswell

Well the button issue seems to be sorted and I'm very happy with that.

Hoping to see the 0.6C release soon

Well.. So far looking good. Saw some nice races yesterday evening. About 20 racing. Really like the connection quality details in the connection list. Also experienced that the connection is more reliable, had four clients running and during a lag session only B10 stayed connected, the other three (B4) timed out.

Only thing I noticed is that when clicked through the field randomly that it takes some time (~2 sec) to draw the car. So the camera is focused on the position but you don't see a car (follow view). Maybe thats me, or its by design, I don't know. *oops, settings got resetted by my own mistake and multiplayer speedup option was activated.

Nothing else to report. Today not many people are capable or wanting to try this test patch. Too bad. An official release is welcome when there are no real show stoppers anymore.

Then the focus can be back on a new race track ( )
.

Suggestion someone just made;

Also detailed line quality indication in join screen. Could be useful especially at the start of race league events. I wonder why people still time out when the track changes but hhmm... Well... Happens for years already.

Could be something related with track loading at client end. I never time out on track change,I'm pretty sure that's because I have low quality textures (because of the weak gpu),which takes shorter time to load.

In my experience, it is usually the client's load times that cause the disconnects on track change, although IIRC occasionally people with very bad connections do get taken out by others who are loading slowly.