new armagetron sound scheme
-
- Match Winner
- Posts: 641
- Joined: Sun Jul 10, 2005 9:14 am
The structure of our packets is simple; they are organized in two bye words.
The last word is the ID of the sender; 0 for the server and 1..16 for the clients.
The rest of the packet is split up into messages.
Each message starts with the message type, message length and message ID (don't know by heard in which order), and then the data of that message. Every message type has an own sub-format.
Packets have varying length. You can get guesstimates from the statistics that are printed every round. Just divide the number of bytes by the number of packets. The UDP header overhead (forgot how much it was) is included in these statistics, so to get our real data length, you need to subtract it.
Why do you want to know?
And please cut that crap talking. All of you
Edit: typo
The last word is the ID of the sender; 0 for the server and 1..16 for the clients.
The rest of the packet is split up into messages.
Each message starts with the message type, message length and message ID (don't know by heard in which order), and then the data of that message. Every message type has an own sub-format.
Packets have varying length. You can get guesstimates from the statistics that are printed every round. Just divide the number of bytes by the number of packets. The UDP header overhead (forgot how much it was) is included in these statistics, so to get our real data length, you need to subtract it.
Why do you want to know?
And please cut that crap talking. All of you
Edit: typo
Last edited by Z-Man on Tue Nov 22, 2005 2:32 pm, edited 1 time in total.
-
- Match Winner
- Posts: 641
- Joined: Sun Jul 10, 2005 9:14 am
Well, you're right in one point: doing NAT translation for UDP is, in principle, more difficult than TCP because you can't rely on the existence of connections. So there may indeed be early Firewall/NAT boxes that handle TCP, but not UDP.Walking Tree wrote:hmya.... i was expecting firewalls to be a bit dumber...
Paniq303: Well, there are lots of unused bits. There is room for improvement in the form of compression. And when objects are synced and variables have not changed, they are transmitted again anyway, one could get rid of this redundancy. But all that makes the protocol harder to debug, and debugabillity is of very high priority for 0.x versions, so we did not do it. It's an option for the future.
No need. I can adapt
Code: Select all
cat /dev/random