quote:
Original post by Crispy
Mmkay - so would this be the correct scheme (?):
1) Server has a listener and a pool of sockets
2) Client only has one socket with which it connects to the server
3) Whenever there''s an incoming request for a connection on the server side, a new socket is opened for conversation both ways.
A couple of questions, though:
1) If there is no listener on the client''s side, how does the client know when there''s an incoming message? There still has to be a separate thread to poll the listening socket (which in turn constitutes a listener), right?
2) Is the socket automatically closed on the other end if, for exaple, the server shuts down for no too apparent reason (Windows crashes)?
Thanks,
Crispy
Please don''t take this the wrong way but it sounds like you need to do a quick brush up on TCP/IP and socket-based programming in general.
Quick run down:
TCP/IP is a bi-directional communication channel. In Winsock and TCP/IP end-point is represented by a socket descriptor (a socket.) This socket descriptor is managed by the OS and underlying transport implementation and your application only receives a handle to it. This socket descriptor contains information such as the state of the "connection", address family information, socket options, end-point info etc. This handle, represented by a SOCKET variable, is what you pass to socket functions to perform operations on the socket.
Now, in the context of you application, when the client connects to the server the server "accepts" the client''s request and assigns a socket to the client. The socket on the server represents the server end-point of the client-server connection. This client-server connection is bi-directional . Both the client and server can issue send and receive commands on this virtual "channel".
Let me say this again, the server can send()/recv() data to the connected client using the socket handle that it gets back from accept(). This socket handle is bound to that specific client and no other (at least for TCP/IP.) So when a server receives a message from the client, on that socket, the server can send the response using that same socket.
Depending on your architecture your server can send/recv without waiting for client information. The alternative is to use a request-response mechanism (like HTTP.) The client sends a request ("message") to the server and then waits for the server to respond. This is probably the best mechanism for your game.
quote:
Original post by Crispy
1) If there is no listener on the client''s side, how does the client know when there''s an incoming message? There still has to be a separate thread to poll the listening socket (which in turn constitutes a listener), right?
2) Is the socket automatically closed on the other end if, for exaple, the server shuts down for no too apparent reason (Windows crashes)?
1. See long ass explanation above.
2. The socket will be "closed" when the process either a) closes, b) crashes, c) disappears into a blackhole. The only difference is "how" the socket is closed. The socket end-point can be "reset" (server crashes/ TCP/IP is shutdown), or gracefully (server calls shutdown/closesocket.)
You can detect when a TCP/IP socket closes gracefully by testing if send()/recv() return 0 bytes. If either of those functions return 0 bytes then the connection has been gracefully closed at the other end. This detection works both on the server and the client. If you get a SOCKET_ERROR and WSAGetLastError() returns WSAECONNABORTED, WSAECONNRESET or WSAETIMEDOUT, you know the connection at the other end has been abruptly terminated (a "hard" close.) This could be because the client/server crashed or the network cable was unplugged etc.
Whew. Well I''m off. Hopefully this helped you out. If you have anymore questions, please feel free to ask.
Regards.
