[gameprogrammer] Rich Interent Application System for Games

Hi,

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.

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.

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.

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.

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.

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.

This would also allow for setting flags of various events. For example:

  if (client_screen_was_resized) {  // test local flag for event
    get_current_screen_size();  // available locally now
    resize_my_app_screen();  // do it

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%.

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.

Thank you in advance,
Chris

--=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

Other related posts: