[gameprogrammer] Re: Rich Interent Application System for Games

TCP is a lossless protocol, so yes, you can get rid of the ACK
messages. Ofcourse, UDP is quite a lot faster so you might consider
using that instead (datagrams instead of sockets), and then you need
the ACK messages..

May I ask you why you are doing this? If you are obliged to download a
client application (analogous to the web browser application) at the
internet cafe' anyway, it seems downloading a "whole" application is
the way to go..

/Olof

On 6/10/05, Chris Nystrom <cnystrom@xxxxxxxxx> wrote:
> Hi,
>=20
> I am working on a rich internet application system for games. I want
> it to be client/server and to be able to use plain old C, by linking
> in a library. The way it works is that there is an SDL front end. You
> type in a URL and it makes a network connection to start a program on
> another server (currently using INETD) and this program (currently
> written in C) makes RPC calls back to the SDL front end program.
>=20
> Although what I have is still very primitive, it seems to work fine.
> It has drawing primitives and handles images, music, sound, fonts,
> etc. Video is planned by not yet implmented. However, as you might
> expect, I have a problem with latency. I can achieve about 2500 rpc
> calls per second on my LAN, but when I go to the local wireless cafe,
> I only get about 25 calls per second. It works at this speed but is,
> of course, significantly slower.
>=20
> I realize that I am never going to achieve anything like the speed of
> a local application, or even an application on a LAN, but anything I
> can do to speed things up is a big win, as speed is obviously the meat
> of the problem.
>=20
> FYI, my RPC protocol is very simple. It just transmits a buffer with
> the first data element an integer. The integer tells what function it
> is, and therefore the remaining parameters and type of data is known
> and unpacked from the buffer. Every call is ACKed, or in some cases
> (such as client state), data is packed and sent back.
>=20
> I have been thinking that I can get rid of the RPC responses (and thus
> the time it takes to wait for the response), by having 2 channels
> instead of just the one I am currently using. I would have one channel
> for each direction of communication.
>=20
> One channel would be from the program running on the server back to
> the SDL client which would used to tell the client to play a song or
> draw an image, etc. The second channel would be for the SDL client to
> communicate back to the program on the server and would communicate
> events such as key and mouse events, screen resizes, etc. The library
> (linked to the binary on the server) would listen and update this
> information in another thread. That way if any routine needs this
> information it can get it from a local call, and not have to make an
> RPC call. By constanly pumping this data through this second event
> channel, this would save the program the time of having to ask for it
> and then waiting on a response.
>=20
> This would also allow for setting flags of various events. For example:
>=20
>   if (client_screen_was_resized) {  // test local flag for event
>     get_current_screen_size();  // available locally now
>     resize_my_app_screen();  // do it
>=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%.
>=20
> So anyway, I thought I would describe this new architecture in this
> forum and get the collective group wisdom on it before I started
> coding it.
>=20
> Thank you in advance,
> Chris
>=20
> --=3D20
> E-Mail: Chris Nystrom <cnystrom@xxxxxxxxx>
> Business: http://www.shaklee.net/austin
> Blog: http://conversazione.blogspot.com/
> AIM: nystromchris
>=20
>=20
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>=20
>=20
>


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

Other related posts: