Greetings everyone.

I'm not sure whether this is the correct forum thread to post about DCON's buffer size or not, if it isn't, my apologies.

Recently, to my surprise and complete ignorance towards DCON's capabilities, Bass-Driver told me that our cruise insim was sending too many data per second and it was overloading DCON's buffer size of 16KB, now I take insim optimizations as the very first priority for obvious reasons but this hasn't crossed my mind at all since I really didn't pay that much attention outside of insim programming.

Now I want to know, Do any of you have a server running with an insim? If so, what is your data rate (bytes) per second PER player that is being sent to DCON? This question can have a lot of variations since many insims are implemented differently but I want an insight.

If you have encountered an overloaded buffer, what did you do to counter this issue? For me, I had to eliminate a loop that would refresh a GUI with 27 buttons per second, this in itself was sending around 1,250B/sec/player or 1.25KB/sec/player, and this number can really go high to 2,250B (2.2KB) if the player has GPS open, other GUI elements that update each second etc, it's simple math, we have 46 open slots in our server, so if a server has 25 players and each player is sending an average of 1,500B (1.5KB) per second, It would hit 37,500B/sec (37.5KB) which is 21,500B (21.5KB) over the buffer size! This would cause issues with the insim timing out and buttons glitching out etc...

Also, do you think 16KB as a maximum buffer size for DCON is too little? Personally I would have made it at least 128KB for obvious headroom and futureproofing...

Use ssd

I haven't got any useful reference from PiranMOTO - I don't send anywhere near that much on any of the servers. The closest I've come to it is sending an entire layout's worth of objects via AXM all in one go - I'd removed the delay by mistake - and nothing bad happened, they all loaded. That would have been to local LFS rather than DCON, though.

Are all 27 buttons changing each second? If they're not, you could save traffic by just sending what changes each time.

Quote from Racon :

I haven't got any useful reference from PiranMOTO - I don't send anywhere near that much on any of the servers. The closest I've come to it is sending an entire layout's worth of objects via AXM all in one go - I'd removed the delay by mistake - and nothing bad happened, they all loaded. That would have been to local LFS rather than DCON, though.

Are all 27 buttons changing each second? If they're not, you could save traffic by just sending what changes each time.

Not all 27 buttons are changing each second, that's my fatal mistake. However I have eliminated the 1 second loop completely since honestly, thinking about it, a loop isn't needed for this matter.

Now each player is sending between 25-250B (if GPS loop is running) per second and I consider this a MASSIVE improvement.

Edit: Forgot one point, it was massive headache cuz I had to re-open the static buttons when a button needs to be updated, this could've been avoided/never happen if the buffer size wasn't a laughably small 16KB.

Just a another note:
iceman121 is having a testversion of LFSLapper, where i "fixed" the packetsize (IS_BTN) of each button.
Each empty button was sending 28 bytes instead of the documented 12 bytes.

Quote from iceman121 :

too little?

Depends on the level of efficiency. 27 buttons a second per player sounds pretty extreme to me. Are you sending/deleting/sending buttons all the time? This is not how it should be done, only updates should be send. And there is also the global button (send to all connections).

Quote from cargame.nl :

Depends on the level of efficiency. 27 buttons a second per player sounds pretty extreme to me. Are you sending/deleting/sending buttons all the time? This is not how it should be done, only updates should be send. And there is also the global button (send to all connections).

Yes it does sound extreme and the thing is, these buttons update at random intervals depending on what the player is doing and his statistics, thus each player has a private unique button instead of a global button and why I made it to update each second, saves a lot of hassle.

However, I still find the 16KB buffer size is quite low, as it would limit and kill the flexibility of what we could do with our creative insim ideas.

I joined this morning and I got a general idea what you are on about. Thats why the update delay on servers like [TC] citydriving is longer of course..

I think we are years away before these kind of requests will be honored so don't hold your breath

As far as I know, PRISM never encountered that limit. Most of the packet sending and receiving methods were written by Victor, so maybe take a look at PRISM's implementation as a reference. Considering that he is an LFS dev, he would have more information than I would, or anyone else for that matter.

Quote from Dygear :

As far as I know, PRISM never encountered that limit. Most of the packet sending and receiving methods were written by Victor, so maybe take a look at PRISM's implementation as a reference. Considering that he is an LFS dev, he would have more information than I would, or anyone else for that matter.

I would assume Victor might've possibly implemented some sort of packet splitting algorithm. That would be interesting to see and learn how it is implemented if that's the case, as it would solve the obvious overloaded buffer issue, but got me thinking wouldn't it cause more latency/delay since each packet would have to be split and sent individually?

exactly.. splitting data doesnt save data, it generates even more data

TTL Hip Hop..
0.999=1