Sign in to follow this  

Google Lively and game networking over http

This topic is 3312 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The conventional communication method for game networking is tcp/ip (sockets). However, this method does not pass firewalls. Http on the other hand is basically a synchronous type of communication. The client initiates a request and the server responds. Apparently, it does not allow sending requests from server to client, to move another player's avatar, for example. I'm using another method, which is rare but known: I'm opening an http get request, while the get never ends, for the download side; and an http post request, while the post never ends, for the upload side. This allows asynchronous communication between client and server, above http, so as far as firewalls are concerned it maybe a web browser (doing a long upload or download, for example). The server side is implemented as an ISAPI extension (windows server…) It worked fine for me, until few months ago, when antiviruses like AVG and Kaspersky started to filter out this way of communication. They do not allow POST-s without pre specifying their lengths or gets that return with HSE_STATUS_PENDING. Most metaverse applications like second life, MTV, Kaneva etc. use sockets. However, Google Lively uses http. They do not use http in the way I just mentioned but, as far as I could sniff, they send a lot of http requests. I guess that some returns with commands and some don't (if nothing to do from the server's perspective). It looks like they have succeeded to create an asynchronous communication, over http, that pass firewalls. I would like to know if anyone has any experience with using http for game networking, if you have any information or guesses about how Google Lively are doing that or any other comments on the above.

Share this post


Link to post
Share on other sites
Quote:
Original post by yeilamThey do not allow POST-s without pre specifying their lengths or gets that return with HSE_STATUS_PENDING.


So specify the length. Write whatever goes into that at your own pace (firewall cannot dictate how frequently you or the peer sends something), when you reach the specified length, start a new request, and continue from where you left off.

if you want uninterrupted service, use two overlapping requests. When one fills up, the other takes over.

Quote:
I would like to know if anyone has any experience with using http for game networking, if you have any information or guesses about how Google Lively are doing that or any other comments on the above.


I'm not familiar with Lively, but one thing to keep in mind is the Google's infrastructure. Many of their applications rely on AJAX, so an endless torrent of small HTTP requests is something they have likely learned to handle.

Shoutbox, for example, simply has a client-side timer that issues a http request every few seconds, but it's intended for simple servers.

Asynchronous transfer can be reached simply by issuing 5 requests per second, and response to each contains all that has happened in that time. It's not that much different from typical network loop.

Contents of HTTP request/response do not strictly need to match each other, as long as they respect the requirements of protocol. But if application can interpret different behavior, then they can be completely unrelated.

Share this post


Link to post
Share on other sites
HTTP is a protocol on top of TCP/IP, so clearly TCP/IP can pass firewalls or HTTP wouldn't work :-)

The problem you'll get to, though, is that HTTP proxy servers will wait for the full request to fill up before it gets handled. Thus, you can't "pre-allocate" a bunch of data and then trickle it up; you have to actually provide a single packet as a single request.

The HTTP protocol has two options to deal with this. The first option is Connection: keep-alive; the second is the UPGRADE/CONNECT mechanism. Unfortunately, proxies aren't required to honor either of those, so your fallback has to be to issue a single HTTP request for each packet you want to send, and similarly keep a single HTTP request open for polling return data all the time.

That is not going to be very efficient :-)

Share this post


Link to post
Share on other sites

This topic is 3312 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this