GNet High Bandwidth Usage
BlitzMax Forums/BlitzMax Programming/GNet High Bandwidth Usage
| ||
| With no GNetObjects, syncing ~60x a second, GNet seems to use about 500 bytes/second. With 1 object, being written to 40x a second added to the system, the bandwidth usage jumps to 5k/second! The object has 1 string in it "1.42" and 10 floats. I'm not sure how this is represented internally, but I really doubt that the memory used to represent that, even uncompressed, is 1/40th of 5k. Does anyone know why there is so much bandwidth use, and how I can get around this? |
| ||
| Thats 115 Byte per "Write" for the object and the maybe-overhead of GNet. 10 Floats - 40 Bytes (I assume each as 4 Bytes Storage). The String depends on the internal "min length" - so minimum I assume 4 Bytes per Character (if unicode or so) too) - would be 16... So minimum the Object takes 56 Bytes without overhead/control ... using TCP instead of UDP you get some checksums and order-control added ... which may bring it to the 115 Bytes. Using UDP you would may be able to get it to ~2KiB/s. bye MB |
| ||
| Ethernet frames are always at least 512 bits (64 bytes) due to collision detection. So sending nothing at all at 60 Hz, should give you 60x64 bytes (or 3840 bytes) of steady traffic. Now there's a fair chance that GNet optimizes this if it notices that no objects have changed state, it doesn't send out any packets. Does anyone know why there is so much bandwidth use, and how I can get around this? Send larger packets, less frequently. |
| ||
| Yes, 60 times per second seems like a lot. I would think you could cut that way down... |
| ||
| Only send changes... As long a variable hasn't change, there is no need to send it to the other side (coz it already has the value of this variable). bye MB |
| ||
| Sending at 16ms sounds like quite a very lot considering that most peoples latency is 30ms+ which means double to tripple send of the same data until it is acknoledged by the other host and potentially reordered (enet does sequenced delivery so if you sent packet 1,2,3 and then packet 1,3 arrive, packet 3 will not be given through until packet 2 has arrived as well even if it has to request it 20 more times. But enet is intelligent enough to buffer messages already received) So better raise the network update handling to something more realistically like 32ms or if you don't need action / high speed even 64ms (ie every 4th frame or by using a timer and a simple event hook) |
| ||
| Preface: this is my first foray into multiplayer. I'm unclear on how to work this out - because I need to call GNetSync as often as possible in order to decrease the potential gap between someone firing a shot and the result of that shot to something not-noticeable. If I update 30x a second, or every 33ms - worst case: the gunshot can be sent after 33ms from the originating computer, then 33ms after that the host picks it up, creates gunshot fx etc, then 33 ms later sends it, and then 33ms after that it's picked up - so the click-effect time to the user is around 120ms in the worst case - and thats with no network lag either, unless im misunderstanding this. Also, GNetSync only transmits objects which have been modified, and I only modify objects which have moved, etc - so there doesn't seem to be any wasted space in the send. However, with 4 gnet objects updating it takes 12k/second, and with 20 or so updating gnet objects - 8 players (in two game instances) and 12 guns, it uses constant up/down of about 10-12k a second. And with 60 guns, its about 60k/second. I think this must be related to what you were saying MichaelB about a minimum size. However if I have 2 players and 4 guns (in 2 instances), it's around 12 k - adding 1 player and another 2 guns in another instance it leaps to 36k! This is, I assume, because each game instance (which uses 6k to communicate its state to a partner) is now communicating to both, and so sending 12k each. This is already waaay above the acceptable limit to join a player on ADSL in my hometown of Providence Rhode Island - where I tend to get around 20k upstream. Does this mean its time to give up the project using GNet and peer to peer, and attempt to rewrite using a peer / server model? Or am I missing something I can use to fix this? I don't need the customary 32 players, but 8 would be nice, and 4 is absolutely minimum. I'd also like regular DSL subscribers to be able to play it. |
| ||
| GNetObject are synced as full not synced slot wise If you want to have more control over it there is the possibility to write your own host - client layer above pub.enet or use vertex BNetEx which replicates the Blitz3D UDP - TCP functionality at OO level but with streams which is much simpler and has a lot more power. GNET is not meant for realtime and you will not be able to scale it to that. Its for chat or turn based stuff, sorry. (aurora had once a network system basing on BNet. Ported it over to the current BNetEx but as it not opensource anymore I can not offer that for BM users to use in their environments) |
| ||
| Is that why my gnet tests didnt always work? sometimes clients would recieve data, sometimes not. |
| ||
| hmm haven't checked GNets implementation but ENET which is used for it, supports reliable UDP ... so theoretically stuff should not be lost unless you wanted it to. But keep in mind. if a packet has to be resend, a single gnet update might cause a double update, so you could miss the data inbetween if you react to the output "at the end" |
   |