MSGs & streaming data
Author
[Windows]
I was wondering if anyone could take the time to explain to me how a game (or, generally, any windows application) communicates with a server; with 100% interest in the client-side aspect of the process...
In other words, a game server needs to update a client to display changed enemy information on the screen; let's say the enemy's "life" value was at 100%, but because of damage inflicted elsewhere (other players, the enemy's ailing health, whatever) he is now at 70%. Let's call this information EndBoss.life; thus, EndBoss.life now is 0.7.
The server needs some way (algorithm or protocol) to serialize EndBoss.life and pass it over the network (in this case, it is the Internet; not some local net). When the client machine receives the serialized EndBoss.life:
(a) At the machine level, what apparatus "intercepts" the signal? A port? A modem? How does this mechanism relate to the Windows OS?
(b) How does "it" (the OS?) know what application to send EndBoss.life to? For example, if Microsoft Word is listening for updates, how do we prevent it from receiving EndBoss.life?
(c) How do the running game (the application), Windows, and the "intercepting mechanism" (port or otherwise) all relate and work with each other?
(d) At what point does serialized network data get packaged into a Windows MSG struct? This goes for incoming messages received from the "port", as well as outbound messages that are trying to be sent back to the game server.
Thanks for any help here,
ply
Quote:(a) At the machine level, what apparatus "intercepts" the signal? A port? A modem? How does this mechanism relate to the Windows OS?
TCP/IP network stack. It's OS agnostic.
Quote:(b) How does "it" (the OS?) know what application to send EndBoss.life to? For example, if Microsoft Word is listening for updates, how do we prevent it from receiving EndBoss.life?
Word doesn't really do much with this, nor does the OS. Applications that connected the sockets read and write data that they are free to interpret in any way they want. For anyone outside of that pair, the connection is random stream of bytes with no meaning.
Quote:(c) How do the running game (the application), Windows, and the "intercepting mechanism" (port or otherwise) all relate and work with each other?
Socket tutorial.
Quote:(d) At what point does serialized network data get packaged into a Windows MSG struct?
Hopefully never. That is just the case a very specific, apparently very problematic approach of handling certain Microsoft specific API.
Networking isn't concerned with what is sent over it, it transmits and receives bytes. What the applications make out of it is completely up to them.
But do go through TCP/IP and socket tutorials.
Author
Antheus,
Thank you for taking the time to answer these questions. I will definitely pour over the tutorials you recommended.
In the meantime, I am worried that maybe I asked the wrong question, because your answers for (a) and (b) were generous and a little helpful, but not what I was looking for.
It would seem to me like any Intel-based Windows PC would have some mechanism that is essentially a "singal watcher and router," that sits at the client-end of the Internet connection, waiting for information to come in.
When it receives incoming information, it must have some way of delegating where that information goes (i.e. the intended destination application). Now you mentioned that TCP/IP doesn't care what is being sent, and that to applications falling outside of a socket "pair" the bytes are meaningless.
To me, this indicates that some mechanism must be responsible for inspecting the incoming info for a "Socket ID" and then alerting (somehow??) the appropriate application to begin reading/interpreting this info.
How far am I off, here? Can you clarify:
(e) This Socket ID prediction of mine, and
(f) How "mysterious routing mechanism" alerts the appropriate app to start reading?
Thanks again for any help,
ply
Thank you for taking the time to answer these questions. I will definitely pour over the tutorials you recommended.
In the meantime, I am worried that maybe I asked the wrong question, because your answers for (a) and (b) were generous and a little helpful, but not what I was looking for.
It would seem to me like any Intel-based Windows PC would have some mechanism that is essentially a "singal watcher and router," that sits at the client-end of the Internet connection, waiting for information to come in.
When it receives incoming information, it must have some way of delegating where that information goes (i.e. the intended destination application). Now you mentioned that TCP/IP doesn't care what is being sent, and that to applications falling outside of a socket "pair" the bytes are meaningless.
To me, this indicates that some mechanism must be responsible for inspecting the incoming info for a "Socket ID" and then alerting (somehow??) the appropriate application to begin reading/interpreting this info.
How far am I off, here? Can you clarify:
(e) This Socket ID prediction of mine, and
(f) How "mysterious routing mechanism" alerts the appropriate app to start reading?
Thanks again for any help,
ply
For higher level TCP libraries, all you will have to do is either:
Server: Bind to a port and address (often just "0.0.0.0") then call Listen. This will allow that socket to be notified of all connection requests made on that port. Connections made will result in a new socket since the listen socket does only that - listens. So you will have a socket for every connected client plus the listen socket.
Client: Simply enter the address (public IP of the server) and port to connect to. If the server is listening, it will be notified of the connection request. The server can then accept or decline the connection.
Once the connection is established, the client and server can communicate by just sending bytes to each other. TCP guarantees that these bytes will arrive in order, and, as long as the connection is alive, they will arrive. Since TCP is a stream-based protocol, one Send() does not equal one Receive() (many sends can result in one Receive(), especially with Nagling enabled (see FAQ)). Often times people use a custom header to state the size of the message sent so they know where one message ends and the next begins.
How to make use of the information is up to you. HTML, for instance, is just a bunch of jibberish unless you (or a program) knows how to read HTML. Frequently people will assign an "id" to their messages to figure out what kind of message it is. For example, a message for chatting may send the word "chat" for the id while a movement message would have a "move" id. Of course, such long words are not optimal for the ids, but efficient data packing isn't really something you should focus on yet.
So, unless you are using a very high-level library, it is up to you to make meaning of all the bytes sent. They can mean whatever you want them to, too. No one is stopping you from having a message that says "AttackMonster1000" actually make your character start break-dancing.
Server: Bind to a port and address (often just "0.0.0.0") then call Listen. This will allow that socket to be notified of all connection requests made on that port. Connections made will result in a new socket since the listen socket does only that - listens. So you will have a socket for every connected client plus the listen socket.
Client: Simply enter the address (public IP of the server) and port to connect to. If the server is listening, it will be notified of the connection request. The server can then accept or decline the connection.
Once the connection is established, the client and server can communicate by just sending bytes to each other. TCP guarantees that these bytes will arrive in order, and, as long as the connection is alive, they will arrive. Since TCP is a stream-based protocol, one Send() does not equal one Receive() (many sends can result in one Receive(), especially with Nagling enabled (see FAQ)). Often times people use a custom header to state the size of the message sent so they know where one message ends and the next begins.
How to make use of the information is up to you. HTML, for instance, is just a bunch of jibberish unless you (or a program) knows how to read HTML. Frequently people will assign an "id" to their messages to figure out what kind of message it is. For example, a message for chatting may send the word "chat" for the id while a movement message would have a "move" id. Of course, such long words are not optimal for the ids, but efficient data packing isn't really something you should focus on yet.
So, unless you are using a very high-level library, it is up to you to make meaning of all the bytes sent. They can mean whatever you want them to, too. No one is stopping you from having a message that says "AttackMonster1000" actually make your character start break-dancing.
(f) How "mysterious routing mechanism" alerts the appropriate app to start reading?
This depends on how you have setup your sockets. Normaly (just using plain 'old tcp sockets) they will not notify you in anyway. You will have to use select() to poll the os for data stored for your spesific socket. You can also ofc use read() to get the data but that will cause your application to block until it get som data. (Can be set to noblocking mode tho ).
Basicly that means that the os will buffer incoming data for you and you have to make sure that you poll for it. If the buffer get overflowed you will start to loose data, and that is something most people look upon as bad.
If your willing to go out of cross platform portability and bind yourself to windows you can always use FD_READ and the like under windows. That will provide you with even based networking.
hope that helps some
cheers, Sondre
This depends on how you have setup your sockets. Normaly (just using plain 'old tcp sockets) they will not notify you in anyway. You will have to use select() to poll the os for data stored for your spesific socket. You can also ofc use read() to get the data but that will cause your application to block until it get som data. (Can be set to noblocking mode tho ).
Basicly that means that the os will buffer incoming data for you and you have to make sure that you poll for it. If the buffer get overflowed you will start to loose data, and that is something most people look upon as bad.
If your willing to go out of cross platform portability and bind yourself to windows you can always use FD_READ and the like under windows. That will provide you with even based networking.
hope that helps some
cheers, Sondre
I see you've posted this twice; please don't do this - ask a question only once, in the most appropriate forum.
Data comes from the wire onto the network card. That does some work and then yields the data to the operating system. In turn, the OS can yield it to applications, as required.
The OS notes where a piece of data came from and where it was sent to. Typically this includes port numbers for both ends of the connection. When an application asks the operating system if any data has come in, the OS is able to use that criteria to pull out only data relevant to the querying application.
'Ports' don't actually exist; they're just essentially a numbering scheme to facilitate this process of multiple applications sending and receiving data to and from the same network card. For example, web servers typically ask the operating system to use port 80, so browsers know to send their requests by default to port 80, distinguishing that request from other possible connections such as FTP, email, etc.
Data comes from the wire onto the network card. That does some work and then yields the data to the operating system. In turn, the OS can yield it to applications, as required.
The OS notes where a piece of data came from and where it was sent to. Typically this includes port numbers for both ends of the connection. When an application asks the operating system if any data has come in, the OS is able to use that criteria to pull out only data relevant to the querying application.
'Ports' don't actually exist; they're just essentially a numbering scheme to facilitate this process of multiple applications sending and receiving data to and from the same network card. For example, web servers typically ask the operating system to use port 80, so browsers know to send their requests by default to port 80, distinguishing that request from other possible connections such as FTP, email, etc.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement