I guess that would depend on how frequently data is exchanged between client and server. If, after the 50kb have been sent out, there is no more communication between server and client for quite some time (say a minute or so) then a connect-per-request can be a possibility.
But since you spoke of a gaming system and clients moving around I would assume that data exchanges happen frequently and are also triggered asynchronously (not only request-response) which would seem to call for maintaining the connection.
If bandwidth concerns you, that will not be solved by disconnecting the clients after exchange as far as I can see. Your software layer should handle how much data is sent to and read from the clients. As hplus0603 mentioned, if the server reads from your client connections you determine how much you are going to allow each client to send in at a time - e.g. just read up to n kb per iteration.
Why do you think you need to send so much data for positional packets? Maybe you can tell us what kind of game it is (2D / 3D) and which elements other than a change of position are involved when moving.
c# sockets multi client/server implementation
Connection of a TCP socket requires one round-trip (i.e. the client sends a packet, the server responds). This happens a low level when you call the connect function.
So that would mean if you connect, send data, disconnect over and over, you're essentially doubling the round-trip time to the server. So a 50ms ping becomes a 100ms ping.
Keeping the connection open doesn't affect the bandwidth available to the server. The bandwidth is affected by the amount of simultaneous data that is actually being transferred. There's a little bit of extra memory for each open connection required on the server, but it's fairly minimal.
So my recommendation would be to keep the connection open for as long as you need to...
So that would mean if you connect, send data, disconnect over and over, you're essentially doubling the round-trip time to the server. So a 50ms ping becomes a 100ms ping.
Keeping the connection open doesn't affect the bandwidth available to the server. The bandwidth is affected by the amount of simultaneous data that is actually being transferred. There's a little bit of extra memory for each open connection required on the server, but it's fairly minimal.
So my recommendation would be to keep the connection open for as long as you need to...
Author
it is a 2D game as of now.
then later will be implementing it as 3D.
what I am creating as of now is basically just a common structure on how to send player actions to server and receive the result of that action back. About the elements I dont have any idea yet but the Change of position is the only element that could be the largest of them all.
Thank you to all of you that have replied.
It really helped me a lot.
I think that having the connection alive will be the answer for me.
then later will be implementing it as 3D.
what I am creating as of now is basically just a common structure on how to send player actions to server and receive the result of that action back. About the elements I dont have any idea yet but the Change of position is the only element that could be the largest of them all.
Thank you to all of you that have replied.
It really helped me a lot.
I think that having the connection alive will be the answer for me.
If it's a session, where you keep state per connection, then you should not be creating/destroying sessions all the time.
If it's a request/response system like HTTP, where the client will ask for some data and then go away, then you should be using HTTP.
Also, if you need to push data to clients (say, world state updates or other clients' chat code), then you want to use a persistent session/connection, rather than a request system.
If it's a request/response system like HTTP, where the client will ask for some data and then go away, then you should be using HTTP.
Also, if you need to push data to clients (say, world state updates or other clients' chat code), then you want to use a persistent session/connection, rather than a request system.
Author
Quote:Original post by hplus0603
If it's a session, where you keep state per connection, then you should not be creating/destroying sessions all the time.
If it's a request/response system like HTTP, where the client will ask for some data and then go away, then you should be using HTTP.
Also, if you need to push data to clients (say, world state updates or other clients' chat code), then you want to use a persistent session/connection, rather than a request system.
Thank you.
That's what I am looking for.
Ok, I will keep that in mind.
Author
Quote:Original post by hplus0603
If it's a session, where you keep state per connection, then you should not be creating/destroying sessions all the time.
If it's a request/response system like HTTP, where the client will ask for some data and then go away, then you should be using HTTP.
Also, if you need to push data to clients (say, world state updates or other clients' chat code), then you want to use a persistent session/connection, rather than a request system.
Btw, just want to ask some follow up.
Can a HTTP handle a session? I mean having a multiple request/response in a form of HTTP,is it possible?
I want to try that using the C#.NET HTTPListener,but have not found any samples like that.
HTTP is not designed for sessions; it's a request-response protocol.
Obviously the Web required some concept of a session when using HTTP, so they use cookies - small pieces of data that essentially allow a client to tell a server "hey, this request is from the same guy that sent that other request", thus permitting the server to maintain some sort of state associated with it.
But all that is a bit of a hack compared to just using a connection-oriented protocol and storing the state directly with the connection.
If you're sending a constant stream of requests and expecting to receive a constant stream of replies back, then HTTP is probably the wrong protocol for you. Most games will roll their own protocol on top of TCP or UDP for their specific purpose.
[Edited by - Kylotan on November 21, 2008 8:08:48 AM]
Obviously the Web required some concept of a session when using HTTP, so they use cookies - small pieces of data that essentially allow a client to tell a server "hey, this request is from the same guy that sent that other request", thus permitting the server to maintain some sort of state associated with it.
But all that is a bit of a hack compared to just using a connection-oriented protocol and storing the state directly with the connection.
If you're sending a constant stream of requests and expecting to receive a constant stream of replies back, then HTTP is probably the wrong protocol for you. Most games will roll their own protocol on top of TCP or UDP for their specific purpose.
[Edited by - Kylotan on November 21, 2008 8:08:48 AM]
Author
Quote:Original post by Kylotan
HTTP is not designed for sessions; it's a request-response protocol.
Obviously the Web required some concept of a session when using HTTP, so they use cookies - small pieces of data that essentially allow a client to tell a server "hey, this request is from the same guy that sent that other request", thus permitting the server to maintain some sort of state associated with it.
But all that is a bit of a hack compared to just using a connection-oriented protocol and storing the state directly with the connection.
If you're sending a constant stream of requests and expecting to receive a constant stream of replies back, then HTTP is probably the wrong protocol for you. Most games will roll their own protocol on top of TCP or UDP for their specific purpose.
OK thanks.
That really clarifies a lot.
I think I will concentrate more on using the TCP or UDP
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
