UDP based action

Networking & Multiplayer
#21

I’m fooling around with TCP and Serialization right now, and what I think would be a pretty nifty library would be networking with several send methods (like send(), sendOrderGuarenteed() sendGuarenteed()) and a built-in lean-serializer. The problem with the standard serialization is that it tends to send some pretty bloated messages – what a leaner serializer would do is construct a byte array, stick on a header with the serialID number for the class and the length of the array and then flush it through the output stream.

I’ve not sure exactly how much I can save by doing serialization optomization, but once I’m a bit more proficient it is something I’m going to look into… It is pretty easy to add a getByteArray() method to all of the classes I’m planning on sending, but a general solution to this would be pretty useful I think… Not knowing much about reflection I’m not sure how one would access the private and protected members of the class, but java.io serialization is doing it somehow so it must be possible…

#22

It depends on what do you mean by serialization. Of course all kind of packets would know to convert themselves into stream of bytes (or bits). But it is nothing near the default serialization. I’m thinking here about sending 6 DOF float values in 8 bytes[1], not to waste this 8 bytes just to write serialVersionUID.

Any form of ‘generic’ serialization does not fit the bill here. I’m talking about saving single bits of message by various optimalizations - no way to make it useable for RMI and friends.

As for accessing private members of classes:

  1. Serialization possibly can do this by using native methods, so it is not so obvious that you can do this, but…
  2. You can do this through java.lang.reflect, setAccessible(true) - of course you need privilages

I have, for example, used setAccesible to access private native methods in java.util.prefs to access windows registry outside java prefs sandbox (of course JNI would solve the problem, but I preferred to avoid distributing dll only for this single thing).

[1] - encoding offset from player position instead of absolute coordinate, reducing yaw/pitch/roll angles to one byte each, some kind of funny bit encoding - still thinking about it.

#23

I realize that when you’re saving every single bit you can, a generalized solution for sending data isn’t too useful, but consider that you’re still going to have to use at least one byte for an identifier in almost every situation.

For games that aren’t extremely bandwith-intensive (like the one I’m working on, it’s really quite simple) or ones that are going to need high speed connections, the extra seven bytes is not going to cause a problem and it could really be quite useful (it seems to me anyway). Having to sign an applet to get reflection doesn’t sound very fun… is this how java.io serialization works and if so how do they get around requiring these permissions? (You seem to know about this is the only reason I’m putting off finding out for myself)

#24

AccessController.doPrivileged(new PrivilegedAction() { …});

Generally, java.* packages can do a lot of dirty tricks without having to worry about privilages.

As for signing applet - it is really not so big problem I think. I have done it for webstart enabled app and it is very easy after initial hurdle (maybe 15 minutes to do it for the first time and create ant task, 5 seconds on every build later). Of course, without proper paid certificate, client will get a ‘DO NOT RUN THIS’ warning.

#25

Hrm… paid certificates are not on my horizon at the hobby/learning level. :’(

#26

This is really OS dependant but FWIK on most reasonable OSes this isn’t a problem.

#27

[quote]Hrm… paid certificates are not on my horizon at the hobby/learning level. :’(
[/quote]
Well, but if you are talking about hobby/learning level, then asking user to ‘trust’ untrusted code should also be not a big problem. You do not need a valid certificate to sign a jar - you can create your own. It will be just clearly marked as ‘unknown’.

#28

if you browse the old forums, you’ll find a tcp/ip vs udp discussion that Jeff made some great informative points on this subject

#29

I have looked at this. Main pro-TCP argument there is PPP header compression (in addition to reliability which is obvious). If you would like to send hundreds of small messages per second it would probably matter. But for packed stuff it is not so important. Not to mention that more and more people are using cable models/etc - in which it is TCP/IP which has bigger header size.

I would suggest checking out:


[…]
When we ran some diagnostics we discovered that we were seeing some simply unbelievable latencies. 5 and 10 seconds was frequent, and we saw some as long as 50 seconds!
[…]
TCP is evil. Don’t use TCP for a game. You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls.
[…]


[…]
We originally designed Fireteam around TCP/IP because it’s a reliable transport protocol for network traffic. […] As soon as we started doing real Internet tests, we realized that we needed to start sending some packets unreliably via UDP.
[…]
both TCP/IP and UDP. We initially labored under the idea that only one protocol should be used for the sake of simplicity, but it’s best to use the appropriate tool for each job.
[…]


[…]
Until a reliable transport protocol with predictable delivery is available over the Internet, simulations with timecritical delivery requirements will continue to use unreliable protocols, such as User Datagram Protocol (UDP).
[…]

These people have tried TCP/IP and later changed to UDP, at least for some data. I really do not think that they were not apt at TCP programming - it just that this protocol does not work for realtime games.

As for Jeff’s experience with TCP. Were these 4 modem connections really far away ? Something like over the ocean ? Or was it more or less local test, with people divided by <8 reliable hops ? It is possible that in this situation, there was just no noticeable packet loss - and indeed in this case, TCP can win. But real world does not work in this way.

I think that game designer just voted with their feet. How many real-time games do you know, which use only TCP ? I know that UT, quake and NWN all use UDP (NWN would probably manage to live with TCP, but they still decided to use UDP).

Now, there is a question, if TCP should be used as backing protocol, for non-important data. But this is not very important now - I would like to focus on how to implement realtime, move/fire/kill part of game.

#30

[quote]if you browse the old forums, you’ll find a tcp/ip vs udp discussion that Jeff made some great informative points on this subject
[/quote]
… and not only him!