game client/server question
Author
I have been trying to figure this question out all day...
A game (application) is running on your Windows machine, and the game server - located across the Internet - needs to communicate to it.
It would seem to me like any Intel-based Windows PC would have some mechanism that is essentially a "signal watcher and router," that sits at the client-end of the Internet connection, waiting for information to come in. This would be necessary so that Microsoft Word, trying to look for updates, doesn't process information that is destined for the game application.
When it receives incoming information, it must have some way of delegating where that information goes (i.e. the intended destination application). 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:
(1) This Socket ID prediction of mine, and
(2) How this "mysterious routing mechanism" alerts the appropriate app to start reading?
Thanks for any help,
ply
You're not terribly far off, though there's some details which are small but have a large impact on implementation.
Each connecting socket has to open a connection. Their endpoint of the connection is an IP address and Port (for IP communication; there is of course more than one network protocol; just not that you'll find over the internet). The Port is generally the differentiator between what application gets what.
The app though isn't (by default) alerted. It needs to check periodically to see if there's info sitting there for it.
There's a number of 'how do sockets work?' sort of sites that google knows of. Take a look.
Each connecting socket has to open a connection. Their endpoint of the connection is an IP address and Port (for IP communication; there is of course more than one network protocol; just not that you'll find over the internet). The Port is generally the differentiator between what application gets what.
The app though isn't (by default) alerted. It needs to check periodically to see if there's info sitting there for it.
There's a number of 'how do sockets work?' sort of sites that google knows of. Take a look.
Author
Telastyn,
Thanks for the heads up! I will pour through some sockets tutorial this weekend.
In the meantime, two quick questions:
(1) "It needs to check..." ... check what? The port?
(2) I assume it performs this check via the winsock.h API?
thx,
ply
Thanks for the heads up! I will pour through some sockets tutorial this weekend.
In the meantime, two quick questions:
Quote:
The app though isn't (by default) alerted. It needs to check periodically to see if there's info sitting there for it.
(1) "It needs to check..." ... check what? The port?
(2) I assume it performs this check via the winsock.h API?
thx,
ply
It checks with the OS. The api used can vary. If using raw sockets on windows it'll use winsock at some level. Unix-likes will generally have a BSD sockets implementation which winsock is based off of.
Author
I'm not trying to nitpick, I am just having trouble clarifying some minute details:
But then Telastyn goes on to say:
I am concerned with the order of events here at the client side. Serialized, streaming TCP/IP packets arrive at your computer's port. Now what?!?
(1) Does the OS (Windows) interface directly with the port, or is there some "middle-man" in between these?
(2) Do the TCP/IP packets stay in their raw form, or do they got converted to Windows messages, i.e. "WM_TCP_DATA"??
(3a) If they don't get converted to WM's, then how does an application poll Windows to see if information has been received?
(3b) If they do get converted to WM's, are they passed on to the message queue like any other message?
I think getting these answers cleared up will take care of everything else I don't fully understand, thanks, anyone.
~ply
Quote:Telastyn:
...over the internet). The Port is generally the differentiator between what application gets what...
But then Telastyn goes on to say:
Quote:Telastyn:
[the application] checks with the OS. The api used can vary...
I am concerned with the order of events here at the client side. Serialized, streaming TCP/IP packets arrive at your computer's port. Now what?!?
(1) Does the OS (Windows) interface directly with the port, or is there some "middle-man" in between these?
(2) Do the TCP/IP packets stay in their raw form, or do they got converted to Windows messages, i.e. "WM_TCP_DATA"??
(3a) If they don't get converted to WM's, then how does an application poll Windows to see if information has been received?
(3b) If they do get converted to WM's, are they passed on to the message queue like any other message?
I think getting these answers cleared up will take care of everything else I don't fully understand, thanks, anyone.
~ply
The minutiae don't particularly matter. The API you use will detail the method of receipt.
1. The port is a logical construct, so nothing really 'interfaces' with it. Some code interacts with hardware and abstracts that away. Some other code interacts with that to handle IP traffic and abstracts that away. Both are generally separate code from the OS kernel, but is packaged with the OS. It's a matter of semantics then if you consider the code to be part of the OS or a middle man.
2. I'm not sure if winsock provides an abstraction to message-ize the traffic. I think it might. I don't personally use it. I also think it's a moot point if you're trying to understand network stuff in general since that is API specific.
3a. The portable way is to use select, which is a non-blocking query that says "hey! got anything to read?".
3b. I'd presume so.
In general, if you want to know how to implement stuff then check with your API documentation. If you want to know how stuff works so you can design for it, then all this minutiae is irrelevant. If you're just curious... enh, hope that helps! [grin]
1. The port is a logical construct, so nothing really 'interfaces' with it. Some code interacts with hardware and abstracts that away. Some other code interacts with that to handle IP traffic and abstracts that away. Both are generally separate code from the OS kernel, but is packaged with the OS. It's a matter of semantics then if you consider the code to be part of the OS or a middle man.
2. I'm not sure if winsock provides an abstraction to message-ize the traffic. I think it might. I don't personally use it. I also think it's a moot point if you're trying to understand network stuff in general since that is API specific.
3a. The portable way is to use select, which is a non-blocking query that says "hey! got anything to read?".
3b. I'd presume so.
In general, if you want to know how to implement stuff then check with your API documentation. If you want to know how stuff works so you can design for it, then all this minutiae is irrelevant. If you're just curious... enh, hope that helps! [grin]
If your interested in theory some place like How Stuff works can provide you with a nice overview. If your after a little more depth I learnt alot from:
Beej's Guide to Network Programming
If your not a programmer it might be a bit too heavy but I really liked his descriptions and the early parts of the guide are more theory based than code based so might give you some specifics which will clarify exactly how things work.
Beej's Guide to Network Programming
If your not a programmer it might be a bit too heavy but I really liked his descriptions and the early parts of the guide are more theory based than code based so might give you some specifics which will clarify exactly how things work.
Author
Okay, so let me see if I have this straight ;-)
(1) Serialized packets come in to the client's "port," which is really just a buffer that the OS can interact with. I would assume then, that each port (buffer) is assigned to a particular socket instance, and that this is the primary means by which an application can use a socket select() function to check the appropriate port for bytes to read (?).
(2) I would also assume that winsock has some "Socket" data structure or class that is used as an encapsulation vehicle for all the bytes recovered from a select() or read() invocation. With such a struct instance, the application could then interpret those bytes anyway it desires, yes?
(3) Finally, I would assume that there is a way to use winsock to "connect" to any such port on the client machine, and effectively read any/all data coming into the computer, regardless of the application it is destined to go to? (Obviously, the only problem then would be that the serialized information would only be interpret-able by the designated application.)
(1) Serialized packets come in to the client's "port," which is really just a buffer that the OS can interact with. I would assume then, that each port (buffer) is assigned to a particular socket instance, and that this is the primary means by which an application can use a socket select() function to check the appropriate port for bytes to read (?).
(2) I would also assume that winsock has some "Socket" data structure or class that is used as an encapsulation vehicle for all the bytes recovered from a select() or read() invocation. With such a struct instance, the application could then interpret those bytes anyway it desires, yes?
(3) Finally, I would assume that there is a way to use winsock to "connect" to any such port on the client machine, and effectively read any/all data coming into the computer, regardless of the application it is destined to go to? (Obviously, the only problem then would be that the serialized information would only be interpret-able by the designated application.)
Please see also my reply in your other thread. (And the point about not cross-posting.)
1) Packets come into the networking layer. They don't go into 'ports'; ports are just numerical identifiers to help sort the data. Some networking systems don't have any concept of ports. But yes, sockets are associated with individual ports. When you read from a socket, or ask if the socket has data, that association allows the OS to know which data is relevant by comparing the port numbers.
2) No. A socket is not the data - a socket is the means by which you receive the data. You ask the socket for data and it returns raw bytes. Then, you interpret them as required.
3) Yes, if you read through the previous link posted for you, you'll see that the 'bind' and 'listen' functions allow you to begin accepting data on a port of your choosing.
1) Packets come into the networking layer. They don't go into 'ports'; ports are just numerical identifiers to help sort the data. Some networking systems don't have any concept of ports. But yes, sockets are associated with individual ports. When you read from a socket, or ask if the socket has data, that association allows the OS to know which data is relevant by comparing the port numbers.
2) No. A socket is not the data - a socket is the means by which you receive the data. You ask the socket for data and it returns raw bytes. Then, you interpret them as required.
3) Yes, if you read through the previous link posted for you, you'll see that the 'bind' and 'listen' functions allow you to begin accepting data on a port of your choosing.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement