Sockets and DCS.onPlayerTryConnect performance

I'm working on a small server mod that talks to a database using luasockets to send messages to a tcp server, which calls the database and sends back the data results.

I have some logic right now in the onPlayerTryConnect, that if this is a new player connecting, to go to the database to either create a player record, or retrieve the existing one. This works fine when I'm testing outside of DCS (using mock DCS objects to simulate running the game).

I noticed that if I set the timeout too small, the socket:receive will timeout almost every time, failing to get back player information from the database. If I set it to 5 seconds for example I get the information back.

Will this cause any performance impacts on the server or in the multiplayer game for others? I want to avoid the case where multiple people connecting at the same time causes the server to lag or freeze. Is it safe to block/wait on server event calls?

On player try connect needs to return immediately as you are blocking their connection until you return. Think the docs in API.txt specifically say that call needs to return very quickly

Dcs is single threaded (ish) so you want be able to use TCP sockets from lua without causing some performance impact. You could use a lua module written in c/c++ to spawn a thread with a function that dcs can poll to get back data, then do all heavy work on that seperate thread.

If you're shipping data out, use UDP, it's quick and asynchronous. If you have the receiver program on the same system as DCS you don't need to worry about packet fragmentation or packet loss as localhost will always deliver it up to a very large packet size.

I'd also use the on event for player connection rather than the try connect so you don't interfere with their connection.

Hope that helps.

Sent from my ONEPLUS A3003 using Tapatalk

Thanks a lot Ciribob for the info!

I'm using UDP sockets to send/receive from the mission script layer, and the TCP socket is for send/receive to the database (which might be on a different server) - this is mostly so that when the player connects I can fetch the record to determine if they are banned from the server for example (or if they've run out of lives and cant slot in anymore).

Good to know that onPlayerTryConnect needs to return quickly - i may need to retrieve the banlist on mission load and just check if the player is in that list instead of in a loop or something.

Should I avoid TCP sockets in the server mod, and handle that stuff in the mission script layer in a scheduled function?

I would avoid TCP altogether in DCS, just due to the blocking for waiting for read, but its been a while since I tried so I would experiment anyway!

I would handle stuff in a scheduled fashion, but you do have a function in the GameGUI for that rather than having to use the mission environment - onSimulationFrame is called every frame so you can periodically check for data there and then you can control how often and for how long it blocks more easily

Thanks CiriBob, originally i had planned to have the TCP message pumping be done on the mission side, but I've since moved it over to the server mod using the onSimulationFrame handler and checking every few hundred frames or so.

I got around the tcp blocking on read by setting a very low timeout so that the read is instant. The TCP sends are done in other handlers (like onConnect, onDisconnect) and the reads are done in the main loop when available - so far nothing is blocking and performance looks good.

I did run into something else however - I want to have the server mod call the database to get the ServerID and SessionID just as the mission is starting (one time call), and then send this data over via UDP to the mission script side to sync up.

When I try this out - if the server mod loads first, it will call the DB, get the data back, then immediately send a UDP message to the Mission. If the mission has not initialized at this point, then when the UDPreceiver on the mission side is created, that message the ServerMod sent is lost. This only works if the Missions UDP socket is initialized first on that port before the ServerMod sends the UDP response - would you happen to know the order in which things get initialized? Is the Server Mod initialized first, or the mission? I have this one time call done during the onSimulationFrame when the simulation time > 0.

Its a bit of an odd workaround but you could use a mission flag to indicate its ready to receive?

You get your mission to set a flag to true or a value and check from gameGUI when the flag is set:

https://github.com/ciribob/DCS-SimpleSlotBlock/blob/master/SimpleSlotBlockGameGUI.lua#L139

You can also modify that line to set the flag back to normal for a subsequent mission load

Thanks CiriBob! I went with what you suggested using dostring_in to set and get flags, it all loads up and syncs up like a charm.