19 users logged in
Proud partner of GDC 2025
Before posting, review our community guidelines.
Support GameDev.net with a monthly GDNet+ subscription!
Problem understanding network coding.
April 27, 2002 11:12 PM
Ok,
I''m having some serious trouble here.
I am trying to understand how to handle writing network based app. I have the very basic concepts, and can write a simple echo server, no problem - as well as send out query packets to various game udp query ports, but I want to go beyond that.
I have read the tutorials on here, and I have gone to a variety of sites, and I have read from MSDN, but I am lost.
Before I get into any game situation, I want to write a small chat program - one server, multiple clients, etc., etc.
I have been trying to figure whether a thread method or a single thread async is the best, or a multi thread - (one listen/accept, one transmission for all current clients, etc.)
But I just don''t get how to implement it.
I don''t quite follow how to properly implement selects, and to be honest, I''m just plain confused.
Anyone that can offer some help, I would greatly appreciate it - especially if there are any CLEAR tutorials that have a more advanced sample then just a echo server/client - something that can handle multiple connections and so forth.
Right now, I am limited to using libraries I have found on the net, but I would really like to develop my own so I don''t have a bunch of bloat, or missing functionality...
April 28, 2002 08:43 AM
Have you looked at Beej's Networking guide? (See 'Sockets' in my signature.)
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
[edited by - Kylotan on April 28, 2002 9:44:22 AM]
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
[edited by - Kylotan on April 28, 2002 9:44:22 AM]
584
April 28, 2002 08:58 AM
Try http://cyberhipster.com/net/inetprog.htm
It''s the best I''ve found. Easy to understand, still goes through all you need to know for simple applications.
It''s the best I''ve found. Easy to understand, still goes through all you need to know for simple applications.
-LuctusIn the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move - Douglas Adams
April 28, 2002 11:02 AM
Kylotan: Yes, I have taken a look at Beej''s network programming guide - I understand the basics - I run into trouble with the async stuff. I know that M$ does it a bit different the Unix with it''s WSAAsyncSelect() (I think that''s what it is). His multi user chat *almost* makes sense to me - my only issue with his demo code is how does the server know it can send data overall - for example, let''s say the server wanted to broadcast "this chat server rocks" every 30 seconds - how can the server tell that it is OK to send - like the concept of a networked game using udp - if the server needs to keep pumping data to the client, how does the client know when it can send new position info to the server? Plus, he only shows server side, I wish he had a small client demo to work with it...
Luctus: Yes, I had been to his site before, it is what has helped my understand what I do up to this point - but his covering of async sockets has been rather.... non-existent. the creator states its support is in the socket library, but just looking at the socket library doesn''t really help with how to really implement it, I mean, I see the async stuff there, but in Windows case, how would it receive a message that there is something on the socket to receive. Granted, if I threw it in a thread and just looped for all eternity I might be able to make it work - but otherwise, how would I know when I get an accept, or a read or a send?
I''m sure my confusion really shows here. I''m SOOOOO lost. I need the main server to keep running to do background tasks, I figured I''d throw everything into threads, but then comes the problem - send and recv are blocking - which means that the server (or client) has to sit and wait until it can actually send data (in terms of the chat program, that would suck, you type something, press enter and have to wait to be able to send it because you are waiting for data from the server? or you can''t receive data from the server because you are waiting to send?). Ok, so async/non-blocking comes into play. Well.... getting that to work just hasn''t made sense yet...
Luctus: Yes, I had been to his site before, it is what has helped my understand what I do up to this point - but his covering of async sockets has been rather.... non-existent. the creator states its support is in the socket library, but just looking at the socket library doesn''t really help with how to really implement it, I mean, I see the async stuff there, but in Windows case, how would it receive a message that there is something on the socket to receive. Granted, if I threw it in a thread and just looped for all eternity I might be able to make it work - but otherwise, how would I know when I get an accept, or a read or a send?
I''m sure my confusion really shows here. I''m SOOOOO lost. I need the main server to keep running to do background tasks, I figured I''d throw everything into threads, but then comes the problem - send and recv are blocking - which means that the server (or client) has to sit and wait until it can actually send data (in terms of the chat program, that would suck, you type something, press enter and have to wait to be able to send it because you are waiting for data from the server? or you can''t receive data from the server because you are waiting to send?). Ok, so async/non-blocking comes into play. Well.... getting that to work just hasn''t made sense yet...
April 28, 2002 11:09 AM
quote:
Original post by Tancor
Kylotan: Yes, I have taken a look at Beej''s network programming guide - I understand the basics - I run into trouble with the async stuff. I know that M$ does it a bit different the Unix with it''s WSAAsyncSelect() (I think that''s what it is). His multi user chat *almost* makes sense to me - my only issue with his demo code is how does the server know it can send data overall - for example, let''s say the server wanted to broadcast "this chat server rocks" every 30 seconds - how can the server tell that it is OK to send - like the concept of a networked game using udp - if the server needs to keep pumping data to the client, how does the client know when it can send new position info to the server? Plus, he only shows server side, I wish he had a small client demo to work with it...
They can always send anything to each other. The OS buffers the data until they can get around to recieving it. Simultaneous send and receive is no problem.
quote:
Luctus: Yes, I had been to his site before, it is what has helped my understand what I do up to this point - but his covering of async sockets has been rather.... non-existent. the creator states its support is in the socket library, but just looking at the socket library doesn''t really help with how to really implement it, I mean, I see the async stuff there, but in Windows case, how would it receive a message that there is something on the socket to receive. Granted, if I threw it in a thread and just looped for all eternity I might be able to make it work - but otherwise, how would I know when I get an accept, or a read or a send?
You use a select call or something similar to check the state of your sockets every so often.
quote:
I''m sure my confusion really shows here. I''m SOOOOO lost. I need the main server to keep running to do background tasks, I figured I''d throw everything into threads, but then comes the problem - send and recv are blocking - which means that the server (or client) has to sit and wait until it can actually send data (in terms of the chat program, that would suck, you type something, press enter and have to wait to be able to send it because you are waiting for data from the server? or you can''t receive data from the server because you are waiting to send?). Ok, so async/non-blocking comes into play. Well.... getting that to work just hasn''t made sense yet...
Send and recv are blocking, but they typcially don''t have to wait very long at all. Input and output is buffered by the OS.
April 28, 2002 08:54 PM
I guess I don''t see the problem. Select is simple in blocking mode. It just tells you which sockets have stuff ready for you, so you read from them. In non-blocking, you either poll them, or just wait on an event, something like that. (Can you tell I''ve never used non-blocking sockets? 
) But it doesn''t complicate anything. Most people who talk about needing threads for each socket are using some sort of blocking socket as in Java.
The main issue with ''blocking'' is on receives, rather than sends. You don''t want to call ''read'' or ''recv'' and be waiting forever for some data, which is why you rely on select to let you know when there will be data waiting for you. Having said that, it''s worthwhile checking that the send won''t block either. The key to all this in my model is just having buffers between the logic and the sockets. You should be able to send data to the buffer and let the networking code call select to see when it can empty those buffers, rather than having the game logic wait until everything is sent before proceeding.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
) But it doesn''t complicate anything. Most people who talk about needing threads for each socket are using some sort of blocking socket as in Java.The main issue with ''blocking'' is on receives, rather than sends. You don''t want to call ''read'' or ''recv'' and be waiting forever for some data, which is why you rely on select to let you know when there will be data waiting for you. Having said that, it''s worthwhile checking that the send won''t block either. The key to all this in my model is just having buffers between the logic and the sockets. You should be able to send data to the buffer and let the networking code call select to see when it can empty those buffers, rather than having the game logic wait until everything is sent before proceeding.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
122
April 29, 2002 08:38 AM
Kylotan: If I understand your post right it is possible to create a server this way:
In a singlethreaded app, use an array of blocking sockets containing all the sockets for the clients. Check if there is data to be read or if it is okay to send with select(). If possible then issue send or recv command.
And this method should be fast for say 50 clients being serviced at one time?.
Another one of you wrote that if you check with select that data actually can get send, the send() function will return immediately?. I though that send() on a blocking socket would return when the data was actually SEND.. But if the function just copy the data to a before.. and sends it while your server runs.. Im happy to be wrong.. I wrote one multithreaded server. Dont really like all these synchronization issues. And non blocking socket are a bit of a pain. But if I can write a server to serve a game with the above method it would be much easier.
I have only written a small poorly functioning chat server using TCP. Is TCP to slow for a game? im talking about an action game where player coords information and the like needs to be transfered constantly.
In a singlethreaded app, use an array of blocking sockets containing all the sockets for the clients. Check if there is data to be read or if it is okay to send with select(). If possible then issue send or recv command.
And this method should be fast for say 50 clients being serviced at one time?.
Another one of you wrote that if you check with select that data actually can get send, the send() function will return immediately?. I though that send() on a blocking socket would return when the data was actually SEND.. But if the function just copy the data to a before.. and sends it while your server runs.. Im happy to be wrong.. I wrote one multithreaded server. Dont really like all these synchronization issues. And non blocking socket are a bit of a pain. But if I can write a server to serve a game with the above method it would be much easier.
I have only written a small poorly functioning chat server using TCP. Is TCP to slow for a game? im talking about an action game where player coords information and the like needs to be transfered constantly.
April 29, 2002 11:00 AM
"In a singlethreaded app, use an array of blocking sockets containing all the sockets for the clients. Check if there is data to be read or if it is okay to send with select(). If possible then issue send or recv command.
And this method should be fast for say 50 clients being serviced at one time?. "
It''s the fastest method i know of, using non-blocking sockets (using socket options) is, slightly slower i think, but don''t quote me on that
.
If select() says you can do it, then it can be done, unless something strange has happened in the mean time.
"Another one of you wrote that if you check with select that data actually can get send, the send() function will return immediately?. "
Well, it won''t return immediately as such, i think you mean it won''t block, which it won''t. It will return, as soon as it''s processed the data (which does take time).
"I though that send() on a blocking socket would return when the data was actually SEND.. But if the function just copy the data to a before.. and sends it while your server runs"
It gets buffered by the OS (TCP/IP), and then the network interface, and then it gets sent, resent etc.
"I have only written a small poorly functioning chat server using TCP. Is TCP to slow for a game? im talking about an action game where player coords information and the like needs to be transfered constantly. "
You should use UDP. UDP isn''t actually slower than TCP in transferring packets, it is TCP''s guaranteed delivery system and throttling (including the slow start) that make it less useful for real-time gaming. If you want more details on how/why TCP does these things, you should look it up It is also a good idea to look at the workings of UDP and TCP if you need to make your own guaranteed delivery system over UDP, for things like chat messages. If you read the docs for DirectPlay, you''ll notice that they have modelled their guaranteed delivery very similar to TCP.
And this method should be fast for say 50 clients being serviced at one time?. "
It''s the fastest method i know of, using non-blocking sockets (using socket options) is, slightly slower i think, but don''t quote me on that
.If select() says you can do it, then it can be done, unless something strange has happened in the mean time.
"Another one of you wrote that if you check with select that data actually can get send, the send() function will return immediately?. "
Well, it won''t return immediately as such, i think you mean it won''t block, which it won''t. It will return, as soon as it''s processed the data (which does take time).
"I though that send() on a blocking socket would return when the data was actually SEND.. But if the function just copy the data to a before.. and sends it while your server runs"
It gets buffered by the OS (TCP/IP), and then the network interface, and then it gets sent, resent etc.
"I have only written a small poorly functioning chat server using TCP. Is TCP to slow for a game? im talking about an action game where player coords information and the like needs to be transfered constantly. "
You should use UDP. UDP isn''t actually slower than TCP in transferring packets, it is TCP''s guaranteed delivery system and throttling (including the slow start) that make it less useful for real-time gaming. If you want more details on how/why TCP does these things, you should look it up
It is also a good idea to look at the workings of UDP and TCP if you need to make your own guaranteed delivery system over UDP, for things like chat messages. If you read the docs for DirectPlay, you''ll notice that they have modelled their guaranteed delivery very similar to TCP.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement