[gameprogrammer] Re: Rich Interent Application System for Games

On Sat, 2005-06-11 at 05:16 -0500, Chris Nystrom wrote:
> On 6/10/05, Chris Nystrom <cnystrom@xxxxxxxxx> wrote:
> >=20
> > Also, I do not really need the rpc ACK. I am using TCP and I have not
> > seen any lost messages, and I have no mechanism to retransmit them or
> > anything anway. In this new architecture, I am thinking that both
> > channels can just stream thier data and not have to wait for
> > responses. I am thinking that this should improve the speed by about
> > 50%.
> 
> Actually, now that I think about it, it might be significantly faster
> than 50%. I was thinking that I would be saving the return trip with
> the ACK, but if there is no ack and the data is just streamed out,
> then the second message, or rpc call, would not have to even wait for
> the first mesasge to arrive. It can go out immediately after the first
> one.
> 
> With a streaming protocol, a WAN would be like a dam. A dam takes a
> while to fill up, but once it starts flowing, it flows at the same
> rate as it did before. Likewise a streaming protocol should take a
> while to start and stop (beacuse when you start it takes a while for
> the first packet to get there, and when you say stop it takes a while
> for the last packet to get there), but once it did start or stop it
> should flow at pretty much the same rate as it does on a LAN.
> 
> It would be like when you are talking over a very long distance voice
> communication, like radio to astronaughts. for example. The voice is
> transmitted at the same rate and so it sounds the same, you just have
> to wait longer for the other person to get it, and to receive the
> responce to it.
> 
> However if I am waiting on an event it should still be at most a 50%
> speed gain which should help, and if you are waiting on an event
> perhaps speed is not quite so critical at this point anyway.
> 
> I will find out.
> 
> Chris

I'm coming in late to the discussion, I just took a very long (3,500+
mile) road trip which was great fun. 

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.

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.

                Bob Pendleton


> 
> --=20
> 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
> 
> 
> 
-- 
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx             +
+ web: www.GameProgrammer.com          +
+ www.Wise2Food.com                    +
+ nutrient info on 6,000+ common foods +
+--------------------------------------+



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

Other related posts: