Hi all,
I have a prototype ‘working’ locally, using one application as server and the other client. However, when trying to test over the internet with a friend I get the following error message:
As the title says, these error messages aren’t very clear to me and I was hoping someone could point me in the right direction to start debugging this.
edit: moderator note: we do not remove posts which have replies. I also restored your edited post so the thread is no longer confusing to other users.
Actually, I’m having this problem too. Did you ever solve it?
The exact message I have is ‘no free events for long message’.
I also experiencing such a phenomenon.
After updating to 5.1.0f3 in 5.1.0f2
there are 3 parameters which will affect this:
So, for full answer i need to know, qos of your channel, message size and send rate, if channel is reliable, i need to know rtt between your and your peer…
I’m sending large packets over reliable fragmented when client connects. Essentially the client needs to load a voxel world around them, so lots of data. I can spread it out over several frames. Is it a matter of trial and error? I’ll have to look into those settings. Is it bad to just greatly increase the limits?
Is the voxel world proceduraly generated? Could you just send seed(s)?
Is it bad to just greatly increase the limits?
No it is not bad. This warning just show that you send too much too fast (for library) and need to change configuration or adjust you bandwidth. FragmentedReliable qos was created with the goal do not use them as main qos… I will probably add some sort of streaming qos (with interface like tcp) in the near future for cases like yours.
Some parts might be procedural with seeds, other parts might not. It’s not a traditional voxel game as such, but will have many voxels nonetheless, and I’ll definitely need to support worst case scenarios of having large quantities of data to send.
I use standard reliable for most things, but yeah, my voxel data wasn’t fitting in the 1500 MTU so had to use fragmented. Some kind of stream sounds ideal…
I’m actually seeing the same thing. It’s telling me I have no free events on channel 1
I currently have 2 qos channels:
0 - Reliable Sequenced
1- Unreliable
Currently only NetworkTransforms seem to be using channel 1, seeing as when I remove the channel completely, I get a whole bunch of errors related to the missing channel which comes from NetworkTransforms.
(Invalid channel when sending buffered data, ‘1’. Current channel count is 1
UnityEngine.Networking.NetworkTransform:Update())
I was wondering how an unreliable channel could run out of events and it got me thinking. Could the two channels be flipped? I flipped the qos type on both channels and now, I no longer get that error message and the clients don’t disconnect. On top of it, things seem to run smoother.
Has anyone seen this?
Hi vdasilva.
Unfortunately it is possible:( because sendmessage queue is one per connection and it is shared between channels. There are two different buffers for incoming messages: sendmessage queue, and acknowledgement buffer, where reliable messages are waiting for acknowledgements. While ack buffer is full - no new reliable message will be sent.
Then imagine situation when ack buffer is full, you have additional reliable messages in sendqueue (waiting for send) and you send unreliable message, this message will pushed back to sendqueue and will get stuck by reliable messages on fron of them which are waiting while ack buffer will have free space…
So it is a problem. What we need to decide, should we fix them (by adding two different queues for reliable/unreliable messages) or it is not very important? If you feel that it should be fixed, submit a bug about this.
BTW there is a way to increase acknowledgement buffer by setting config.IsAcksLong = true. Other option is increasing sendqueue by setting config.MaxSentMessageQueueSize parameter
Alex
You can use the new Network panels of the Unity Profiler to see the amount of traffic your game is using. This may help track down the cause of this.
We’re running into this error with 5.1.0f3, and we suspect that our clients may be disconnecting due to not being able to communicate with the server for tens of seconds when the server is reporting this error. We are using the ReliableSequenced channel.
Does ConnectionConfig.FragmentSize affect any QoS other than ReliableFragmented?
If I read Alex’s recommendations correctly, we want to experiment with:
Yes correct Chris.
FragmentSize is depends of do you have alternative channels for sending or not and what is a message size for alternative channels. If not FragmeSize should be ( PacketSize - sizeof(possible headers)) (-50 should be safe do not remember exact value)
Probably we need to add some functions for determine possible payload size depending from qos of channels?
Thanks. So, ConnectionConfig.FragmentSize affects ReliableSequenced?
No. it affects Fragmented qos only…
Adding these lines to the Start method of our NetworkManager child class causes a server to immediately disconnect any client (same computer, different process), and give a bad message error:
base.connectionConfig.IsAcksLong = true; // larger ack buffer, 64 bit
base.connectionConfig.MaxSentMessageQueueSize = 512;
arghh 
Yes Chris, you’re right. Will fix asap. Thanks for this catch
no problem. We might stay on 5.1.0f3 for a while, are either IsAcksLong = true or MaxSentMessageQueueSize = 256 or higher safe with 5.1.0f3?
“either IsAcksLong = true or MaxSentMessageQueueSize = 256 or higher safe with 5.1.0f3?” - IsAcksLong = true won’t work before fix so u can use larger buffer instead (256). for IsAckLong fix will be available for couple of weeks. Or if it’s
Is it safe to use IsAcksLong = true in 5.1.1f1, 64 bit, Windows?