Closed Taraman17 closed 4 years ago
One more thought on this: It adds a dependency to an external library, which you might not want. So it may well be another way to leave the queuing to clients.
Hi @Taraman17, this is a great idea. I do think enqueuing packets has a very positive effect in terms of performance. I was having issues myself with firing hundreds of requests per minute and having some of them miss the server (It's still unclear to me if it's a library issue or a game server issue).
It adds a dependency to an external library, which you might not want. So it may well be another way to leave the queuing to clients.
I always wanted rcon-srcds
to be a dependency-free library but leaving packet queuing to clients looks counter-productive to me as we should provide the highest level possible of abstraction. Clients should just be able to call basic methods like authenticate()
and execute()
and let the library handle the rest. I'm definetely considering adding queue as a dependency.
Maybe we could implement this in the library. We don't need a full featured queue, but only an array of commands (strings) that gets filled on one side and sequentially read and emptied on the other.
signalling between both sides could be done by events.
Just a rough idea for now:
func commandrReceivedFromCli {
q.push(command)
emit('command received')
}
'command received'.on {
while (q.length > 0) {
Promise (write('command'))
q.pop
}
}
If rcon requests are sent simultaneously by code, the server omits some of the responses or they get otherwise lost in space. Therefore it enhances stability to enqueue these requests and send them one after the other.