Re: NIO UDP and TCP
Jordi wrote:
My application is similar to a 3d game, and many 3d games are said to
use UDP to send positions of people playing in the 3d scenario.
It was with the old io. So I wonder if I need UDP if I use NIO, or I
can program all with TCP and get a good speed+reliable data.
As NIO is so fast and uses just 1 thread, I think the server will not
be so loaded.
You've got two different issues here:
- java.io vs. java.nio
- TCP vs. UDP
These two have nothing to do with each other.
You have articulated the advantages of NIO over the older style quite well.
You've convinced me that the NIO channels will let your server work faster and
scale better.
I already have a NIO solution that uses TCP. Both client and server
use NIO to send data in the form of Java objects converted to byte
arrays. This way this is fast and eficient for they two.
Since you're familiar with NIO and have seen its advantages already, there
isn't any downside to it in a potential UDP-based solution, is there?
Why then use UDP in addition to TCP?
You wouldn't necessarily use UDP in addition to TCP; you might use it instead
of TCP.
TCP is reliable; UDP isn't. In fast-moving 3D games reliability tends to be
less important than latency. If the infrastructure is stable and fast enough,
then UDP packets will just be handled if and as they arrive at the destination
clients. The downside is you have to handle ordering yourself. Late packets
might confuse the client if it doesn't have explicit protocols to handle them.
(Typical - insert if you haven't passed its timestamp yet, discard else.)
There's a nice short summary entitled "TCP vs. UDP" at
<http://www.skullbox.net/tcpudp.php>
.. It was my first google hit on a search for that phrase.
In a game, as the client processes the packets it's received, things like the
position of the Garzon Destroyer can be updated in a leap if you've missed a
few packets. Maybe some of your torpedo shots will miss that should have hit,
or vice versa. As your thumbs wear out manipulating your console, you will
never notice. The client just shrugs its metaphorical shoulders and does the
best it can with the data it does receive.
A mixed architecture will have two communications channels - a TCP one for
critical data like meta-commands and a UDP one for, say, audio/video streams.
Whether UDP is faster depends on how much processing you have to do to handle
things that TCP would have done for you at a lower level, like ordering your
incoming packets. If you end up patching every hole left by TCP's absence,
you might as well let TCP do it for you.
Whether faster matters depends on whether the TCP solution is fast enough.
Take heed of the OSI model of network protocol design.
<http://en.wikipedia.org/wiki/OSI_model>
Also, remember that premature optimization is the root of all evil. Be very,
very certain that what you optimize is actually the bottleneck. That means
test and measure. Starting with your existing architecture as the baseline.
Summary: stick with NIO, now that you have it under your belt anyway. TCP
might be fast enough, and might not even be your bottleneck if you even have
one, which you won't know until you test and measure.
--
Lew