[gameprogrammer] Re: Rich Interent Application System for Games

On 6/20/05, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:
> 
> I'm coming in late to the discussion, I just took a very long (3,500+
> mile) road trip which was great fun.

Congrats. It is good to get away sometimes.
 
> Back on the discussion I have only a few comments: first off TCP/IP is
> bidirectional and the directions work in parallel. You can be sending
> data both ways at the same time. Second, be aware of Nagle's algorithm
> in TCP. TCP will buffer data until a threshold value is reached and then
> send it all as one buffer (how it does it is controlled by Nagle's
> algorithm). This reduces the number of packets sent of the network, but
> introduces a delay into the transmission. There is an option you can use
> when creating a socket that will turn off Nagle's algorithm. (I think it
> is NO_DELAY.) But, it will greatly increase the number of packets sent.
> There is some reason to believe that you can do better by turning off
> Nagle's algorithm and doing you own application level buffering. Third,
> you can send and receive TCP in parallel with processing the requests.
> If the client has one thread that reads packets, one that sends packets,
> and one that processes packets you can get a dramatic speed up in your
> application. It is amazing to see how much of a speed up you can get.

Yes, I  am thinking I will need to  do something like this.

> On the UDP versus TCP question; TCP is designed to be a reliable
> connection that is also a good network citizen. The first part of that
> means that TCP already uses acks and resending to get reliability. The
> second part means that TCP is designed to *slow down* in the face of
> network congestion so that everyone gets a fair chance at using the
> network. UDP does not slow down, but it pays for it by being unreliable.
> If you use UDP you have to implement your on reliability layer. My bet
> is that you can find a library that works like TCP based on UDP that
> doesn't have the good citizen nature of TCP.

Yes, Stevens' Unix Networking Programming has some examples on making
UDP more reliable, and a quick google search reveals thngs like enet
(http://enet.cubik.org/) that look promising. I am thinking at this
point that the fastest possible solution would be 3 threads like you
suggest, but to use UDP instead of TCP.

Currrent status. I was able to quickly whip up a basic UDP library. I
did not worry about reliability as I wanted to see the unreliability
before I fixed it. The first problem I ran into was how to dubug it,
since you can not telnet to the port anymore with UDP to see what is
going on. Before too long I found netcat (nc). Netcat seems to work
very well for UDP debugging.

The next problem that I ran into, was that on the server side I was
using inetd to handle the networking. This worked fine for TCP, but I
am running into issues with UDP. I have a small test program, and it
is starting up fine and getting input, but I can not seem to see the
output for some reason. Still working on this. Might be a waste of
time, but I wanted to basically just change my existing program from
TCP to  UDP and compare the transactions per second, before I redo
everything.

Thank you for your advice,
Chris

-- 
E-Mail: Chris Nystrom <cnystrom@xxxxxxxxx>
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris


---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: