NIO UDP and TCP

[Jordi]

Hello

I need an expert's advice and clear some concepts.

I have a NIO server and a NIO client.
I have a big muddle with all this of TCP UDP and NIO.

My NIO server uses ByteBuffers to send objects converted to bytes.
So it's quite eficient. What it must do is to send chat and java
objects that encapsulate some data.

I am doing a kind of game and I need to send data of position and
orientation of some characters that move in a 3d scenario. I don't
need all positions, I will send some, not all. When people receive
them in their clients, I use dead reckoning to move the people
characters.

But if there's many people in the 3d place moving, I will need to send
a huge amount of data. That's why I used NIO.

I read that was done with UDP Datagrams in the past.

My questions are:
- Do I need UDP Datagrams if I use NIO (sending Objects as bytes)?
- Can UDP used with NIO? Or it needs another connection?
- What has to do TCP and UDP with NIO ?

Sorry for the stupid questions. Just asking to clarify and get advice.

Thanks

Jordi

 

[Mike Baranczak]

- Do I need UDP Datagrams if I use NIO (sending Objects as bytes)?
- Can UDP used with NIO? Or it needs another connection?
- What has to do TCP and UDP with NIO ?

TCP and UDP are low-level protocols built on top of IP (Internet
Protocol). The main difference is that TCP requires the receiver to send
an acknowledgement for each packet received, and in case a packet gets
lost, the sender will try to re-send it. This makes TCP more reliable,
but also less efficient. If you're using UDP, you have to consider the
possibility that some of your data may disappear on the way, or arrive
in a different order than it was sent in.

NIO works with either UDP or TCP. So do the traditional synchronous IO
classes. In my experience, synchronous IO and TCP are easier to work
with, so when in doubt, use those.

Hope that clears things up.

-MB

 

[Lew]

NIO works with either UDP or TCP. So do the traditional synchronous IO
classes. In my experience, synchronous IO and TCP are easier to work
with, so when in doubt, use those.

NIO's complexity is the price for its benefit, that NIO is more efficient and
parsimonious of threads than the java.io stuff.

Its Buffer taxonomy has some very useful properties also.

That said, I've never yet deployed a NIO solution. But it's nice to know it's
there for when the need arises.

 

[Jordi]

Thank you very much Lew and Mike for answering.

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.

My question is if I would need to stablish an UDP connection in
addition to the TCP.

I understand that TCP looses performance making by checking if the
messages arrive and their security. UDP doesn't does, so it is faster
and overloads less the CPU of the server. Am I right?

THis is the key problem:

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. Why then use UDP in addition to TCP?

Thanks for any reply.

Jordi

 

[Lew]

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.

 

[Jordi]

Thanks Lew
Your message resolved all my doubts and helped me to make a decision,
at least for now, to stick on NIO and TCP.
(It also has the advantage of not having problems with firewalls.)
You have a very high ability to explain things.

You explained so well all the potential problems.
I agree that if I had to compute all things in server and client to
check if the packets are ok and in order at both sides (one to
distribute, the other to send) maybe I lost speed and cpu.

I will stick as I have it now, and if problems arise, I will try with
UDP for character moves, and sell the rest by TCP.

Thanks a lot.

Jordi