General Architechture of Server

[Mike]

That often?

How often does it actually break from a real life scenario? Does anyone have an idea? Is it once every few hours/days or once every 20 minutes? If it is the first it might be okay to reload most data from the server to get common state but if it is the later then I’d need to figure out what was missing and recommunicate only that part.

Kind regards,
Mike

[neoskunk]

@Mickelukas

That often?

How often does it actually break from a real life scenario? Does anyone have an idea? Is it once every few hours/days or once every 20 minutes?

I too would like to know this. And does physical distance between client and server have anything to do with it? As I expressed before are my clients even going to be able to finish playing a game (~10 - 20 min) without having to reconnect?

[Riven]

Distance is not really an important factor.

You can have really stable connections from Germany to the USA, while Germany to Spain can be kinda crap. It’s all about the quality of the local infrastructure. Naturally the farther away, the higher the odds you get routed through crappy routers.

For ‘most of us’ it’s safe to assume TCP is reliable. If you want to provide high quality to customers, either for business or for a commercial game, you have to keep in mind that TCP is far from reliable when you have long running sessions. If you can afford the time/work: prepare to recover.

[delt0r]

I would add to Rivens advice. If you can have long sessions, then you should be able to deal with them and recover when things go pear shaped.

I am in Austria and have 8Mbit unlimited. I really do get that too --ran it at 7Mbit for almost a month. However my internet ip number changes 3 times a day, and that causes all my TCP connections to go dark. They don’t get any kind of notification.

If you expect to keep a single TCP connection live for more than an hour i would recommend that you assume this problem is common place.

[Mike]

@Riven

Distance is not really an important factor.

You can have really stable connections from Germany to the USA, while Germany to Spain can be kinda crap. It’s all about the quality of the local infrastructure. Naturally the farther away, the higher the odds you get routed through crappy routers.

For ‘most of us’ it’s safe to assume TCP is reliable. If you want to provide high quality to customers, either for business or for a commercial game, you have to keep in mind that TCP is far from reliable when you have long running sessions. If you can afford the time/work: prepare to recover.

Thanks Riven,

That sounds good. If it is quite stable I’ll put up a system of synching up with the server again in a less fancy way than if it happened every 10 minutes

Mike

[neoskunk]

@Riven

Create a tcp channel, that handles both your traffic and ping/pong behind the scenes (interleave streams). If the ping fails or the pong timeouts, reconnect. Again, this is all behind an abstraction layer. At the game-code level, you’re simply sending and receiving bytes (or highlevel game-packets), regardless of all the mess that occurs behind the scenes.

sorry to bring up an old thread but I need some advice again. How do you set up this ping/pong? Is socket timeout set on both the client and the server?

Currently this is what I am doing on my socket…

socket = new Socket(ip,portNum);
            out = new PrintWriter(socket.getOutputStream(),true);
            in = new BufferedReader(new InputStreamReader(socket.getInputStream()));

for the game data i send strings over the socket and then parse the strings upon arrival. in order to set up this ping/pong would i create another socket and have the client and server constantly sending data back and forth?

edit: what is an interleave stream?

[Riven]

A socket timeout only works for reading from a socket.

Upon a timeout, exactly nothing will happen to the underlying connection: it will remain open and valid, it’s just that the read() call will throw a SocketTimeoutException.

You set a timeout to make sure your app doesn’t endlessly wait if the tcp-connection gets screwed up (unclean disconnect). You have to set the timeout on both server and client.

[neoskunk]

@Riven

A socket timeout only works for reading from a socket.

Upon a timeout, exactly nothing will happen to the underlying connection: it will remain open and valid, it’s just that the read() call will throw a SocketTimeoutException.

You set a timeout to make sure your app doesn’t endlessly wait if the tcp-connection gets screwed up (unclean disconnect). You have to set the timeout on both server and client.

I understand all of this. Seems to me like it would be best to somehow have two streams going. One that has a socket timeout and the other that doesnt. The one with timout is constantly sending data back and forth while the one without timeout sends game data. In the event of a timeout both streams are killed or reconnected. Is this how it is done or are they merged together?

edit: nevermind i guess it would be really easy to merge them. two streams arent necessary

[DzzD]

@neoskunk

I understand all of this. Seems to me like it would be best to somehow have two streams going. One that has a socket timeout and the other that doesnt. The one with timout is constantly sending data back and forth while the one without timeout sends game data. In the event of a timeout both streams are killed or reconnected. Is this how it is done or are they merged together?

by two stream, do you mean two socket ? (you wont have any benefit in using two)

[i]similar seems to have been already mentioned above but :

server side you should keep timestamp for the last packet received for each client and if lastpacket received for one client is too old disconnect it and free its ressource / kill thread etc…

client side you should send a ping and wait for a pong if no pong received within XX ms/seconds/minute (depending on your game) you should try to re-connect to the server

both are done in a higher level layer (application/software layer), this is not dependent of what network protocol you use ( you could even use SMTP (email) )
[/i]