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.

Ok I pretty much understand that. However - suppose I have an open socket between the server and the client ("started" by the client), and the server sends something through that socket. Now, normally I would require a separate thread to receive stuff from the (any) socket - your explanation implies that there is no need for a separate thread - this is the primary part that''s still confusing me. If there is no constant loop to poll the open socket on the client side, then how are messages retrieved from it? I''m sorry if I''m a little (or rather) ignorant - it''s just that school''s a killer at this time of year and I don''t exactly have too much time to spare 8/ - but it won''t be long before I''m going to have to write an entire underlying client-server system for a 3d shooter, so I really do need to understand the basics. Maybe the problem here lies in terminology - my definition for a "listener" basically borders on "a thread that runs and waits for incoming messages and/or connections".

A few things to rectify/specify from my previous post: "Server has a listener and a pool of sockets" - what I mean by a pool of sockets here is an array of (for instance) TTCPSocket objects - each of which can open a separate underlying socket. "Client only has one socket with which it connects to the server" - the client only uses up one socket, therefore it only has one TTCPSocket object.

quote:
If you have anymore questions, please feel free to ask.

I really appreciate that.

Crispy