Choking/Flooding a reliable channel

[Garry Newman]

We periodically send a lot of data over a reliable channel. For some people they obviously get some packet loss, and their connection chokes... and it never seems to catch up - because we carry on sending data (there doesn't seem to be a way to detect that a client is choking?)

They're still technically connected, they still receive the data on the unreliable channels.

Would it be best to try to catch these situations and force a re-connect? Would it be best to flush the reliable channel completely and try again?

[Lewis Walton]

I've actually been experiencing the same problem (happens completely randomly though and I'm not knowledgeable enough to provide any assistance to debug the issue), I've put off asking a question just like this one for some time now but I must admit it's the most confronting issue I'm having with the library, just wanting to say that I'd also very much appreciate a solution to the problem (using rev 377).

I've redone a lot of my networking code since then to avoid using the reliable channel as often as I can so it hasn't happened in a while, but I fear once the game becomes more complex this'll pop up again. Here's hoping you're able to fix the problem!

P.S: Good to know that people like you and Christopher M. Park are using this library to good effect, gives me much hope for using it in projects of my own.

[Fredrik Holmström]

This is a recurring issue I have had with Lidgren also (and one of the reasons I stopped using it), the problem lies in that lidgrens reliable functionality does not handle being overloaded very well or gracefully, and the only real solution to the problem is to send most data using an unreliable-but-eventually-consistent model.

How much and what type of reliable data are you transferring? 

Regards,
Fredrik Holmström

--
You received this message because you are subscribed to the Google Groups "lidgren-network-gen3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lidgren-network-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[lidgren]

That correct, it is a problem. The reliability guarantee means we can't drop stuff, so if the application keeps sending data onto a congested line it'll choke sooner or later - and Lidgren doesn't have any good solution for backing down gracefully (like TCP does). Lidgrens strong points are small, unreliable or sequenced messages with small reliable messages mixed in; if you know you'll be sending large amounts of reliable data you might either want to look into something else (like TCP) or manually do congestion control (send a chunk, wait for confirmation, send another...)

The SendMessage() method will return a NetSendResult enum... if NetSendResult.Queued is returned, this means your send window is exhausted and you may be in an congestion situation.

--michael

On Friday, October 3, 2014 5:00:09 PM UTC+2, Fredrik Holmström wrote:

This is a recurring issue I have had with Lidgren also (and one of the reasons I stopped using it), the problem lies in that lidgrens reliable functionality does not handle being overloaded very well or gracefully, and the only real solution to the problem is to send most data using an unreliable-but-eventually-consistent model.

How much and what type of reliable data are you transferring? 

Regards,
Fredrik Holmström

On Fri, Oct 3, 2014 at 1:29 PM, Garry Newman <garry.newman@facepunchstudios.com> wrote:

We periodically send a lot of data over a reliable channel. For some people they obviously get some packet loss, and their connection chokes... and it never seems to catch up - because we carry on sending data (there doesn't seem to be a way to detect that a client is choking?)

They're still technically connected, they still receive the data on the unreliable channels.

Would it be best to try to catch these situations and force a re-connect? Would it be best to flush the reliable channel completely and try again?

--
You received this message because you are subscribed to the Google Groups "lidgren-network-gen3" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lidgren-network-gen3+unsub...@googlegroups.com.

[Fredrik Holmström]

Yeah, just chiming in here to say that I agree with you, sending a lot of reliable data in a game will just not work reliably. Garry maybe you can shine some light on what and how much data you are sending?

Regards,
Fredrik Holmström

To unsubscribe from this group and stop receiving emails from it, send an email to lidgren-network-...@googlegroups.com.

[Garry Newman]

That's a good point. The chunk sending is probably the way to go, working to avoid congesting and maybe sending a reliable ping pong on that channel - then kicking if we don't receive a pong in a while (because presumably the channel is choking).

With the SendMessage return - am I right to assume that it will always return NetSendResult.Queued if the packet has had to be split?

garry

--
You received this message because you are subscribed to a topic in the Google Groups "lidgren-network-gen3" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lidgren-network-gen3/6AQ94QnVaSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lidgren-network-...@googlegroups.com.

[Garry Newman]

It's basically when entering the game, it sends a snapshot of the visible entities. This can be thousands of entities, I don't have any specific ideas on size - I will find that out though.

garry

--
You received this message because you are subscribed to a topic in the Google Groups "lidgren-network-gen3" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lidgren-network-gen3/6AQ94QnVaSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lidgren-network-...@googlegroups.com.

[Fredrik Holmström]

Okey, you send all of this in one chunk? like a blob? Because it feels like there is no way for the player to be able to see the entire world at once, right? so it should be possible to partition this so that it can be streamed in as the player is moving around?

Regards,
Fredrik Holmström

[Michael Lidgren]

> With the SendMessage return - am I right to assume that it will always return NetSendResult.Queued if the packet has had to be split?

Not sure; I'd have to check the code. The desired result would be that it would return Queued if the number of messages that were added due to lidgren MTU fragmentation exceeds the remaining window size.

--michael

To unsubscribe from this group and stop receiving emails from it, send an email to lidgren-network-...@googlegroups.com.

[Fredrik Holmström]

I would strongly suggest trying to fix this on the application layer instead of the networking layer, pushing a lot of data reliably over UDP using a game networking library is never a good idea.

Regards,
Fredrik Holmström

[Johnathan Free Wortley]

Could you do something where you have a second endpoint, say over HTTP, that the client can make a request to? That's a much better way to handle transferring large amounts of data. Then you don't have to build out that logic yourself.

Johnathan Free Wortley

--

[Michael Lidgren]

Btw, check out the LibraryTestSample/SpeedSample - it uses the GetSendQueueInfo() method to determine when to push more data to avoid congestion.

--michael