Networking ReliableSequenced and disconnected peers (LLAPI)

I'm having an issue where if a peer disconnects/timeouts and the server was still sending some reliable packets their way... these packets block the sending of any other packets behind them, even for other connections. So the whole server comes to a halt, and eventually Send fails because the send queue is full.

I cleanly remove the peer on disconnect and do NetworkTransport.Disconnect(...) on timeouts but this still occurs. Is there a way to manually flush the send queue for the disconnected peer?

Also, am I correct in assuming that Reliable Sequenced only grants sequenced packets per connection? It would be kind of silly to force sequence on every packet globally as one laggy player would lag the whole server but it seems that's what I'm experiencing.

 

Hi I fixed the strange behavior by changing lowering the thread awake timeout, increasing message queue limits and enabling ReliableFragmented on the channel. Just confused on the difference between these..

ReactorMaximumReceived/SentMessages
MaxSentMessageQueueSize
Sent/ReceivedMessagePoolSize... (docs say this is bytes but default is really small at 128?)

I have over 100 NPCs and vehicle with custom items and I send a LOT of packets to synchonize new players on joining and maybe the Transport library was doing packet aggregation automatically? Either way, it works now though I'm worried since the docs say ReliableFragmented is same as Reliable in that it doesn't grant Sequenced order? Hm.

Also what is reccomended for max packet or fragment size... I would assume around typical MTU... 576 bytes?

But thanks again aabramychev, your work on the new netcode is much appreciated. I was able to convert the old Raknet code in my game to the UNet LLAPI in just a few days and appreciate the great performance and control improvements.

My game is at www.brokeprotocol.com if you want to take a look at the scope of the project.

Cheers

 

Thanks for clarifying, aabramychev. I did create a bare bones networking test project sending all manners of packets and disconnecting in many ways but wasn't able to reproduce the problem with ReliableSequenced QoS.

I'll take another crack at it when I get home but the steps are this... I'm excluding masterserver communication thats on a whole different host but could nontheless be involved.

[All packets on ReliableSequenced channel]
Server Starts
Client connects to Server
Server gets the rData Connection packet
Client sends a request for spawn
Server receives, sends a whole lot of world, and NPC packets, and then a spawn packet.
Client receives fine and spawns, everything is good.

Client quits (not nicely disconnects, I haven't tried that)

Server sends a whole lot (maybe 50-60) messages of...
Attempt to send to not connected connection {1}
UnityEngine.Networking.NetworkTransport:Send(Int32, Int32, Int32, Byte[], Int32, Byte&)
... which is expected

The connection finally times out on the server.

New client connects... connects on same connectionID as previous player since that was freed up by the timeout.
Server receives new Connection rData packet.
Client sends request for spawn...
Server just ignores... doesn't receive anything.

Client hangs waiting for data from server but nothing comes. not even a disconnect.

There might be a disconnect a while later from an Error 4 no resources but it depends on a couple things I can't remember off the top of my head.

When I get back home I'll do more testing around. In my game though I have debug.logs on all NetworkTransport functions error output but I don't get any errors aside from a while after the problems with error 4 as detailed above.

Again trying this out again, all is fixed by switching to ReliableFragmented... even Unreliable works if all the packets get through nice and orderly which is easily done on localhost. So I'm guess it's a problem with ReliableSequenced but I was doubting myself as I wasn't able to reproduce in bare bone conditions.

 

Yeah that must be it - I'm running Beta 5.1.0f1 but I'm unaware of where to get patches I'm afraid. I guess I'll just sit tight for the official release on June 9 then. Thanks!