Sockets programming

[Bonj]

I've been following a socket programming tutorial to make a simple TCP
communication program, seemingly without hitches, it appears to work fine.
However the structure of it is to have a server listening for requests from
a client using listen(), and when one connects, it communicates with that
client but only that one. It doesn't listen for more requests.

What I'm wondering is can I have a server that continually listens for
requests from multiple clients, and when *any* client connects, it can
communicate with that client. I'm thinking multithreading is obviously going
to be necessary in some form, but basically my questions are:

1) Can the server use a method similar to that described in the second
paragraph above to communicate with multiple clients at the same time on the
same port, or does it have to use a different port for each client that's
simultaneously communicating?
My initial hunch tells me that I can - because a web server can do it, but
is there anything special to watch out for such as how it has to integrate
with (2),...

2) Is it necessary to have multithreading, e.g. the server spawns a new
thread for each client that connects in order to communicate with that
client.

Sorry if I've overly crossposted but this seems to be relevant to MS C++ and
standard C++ as I'm intending to use it in linux aswell as windows, (the
only thing seemingly different in linux seems to be that it has different
includes and doesn't have to call WSAStartup).

[dave windsor]

That may be true, but the true power of select() is seen when multiple
sockets are in use; testing FD_ISSET usually gets the job done quickly
for me. Implementations using select() for input polling usually
involve a very short loop no matter how many input sources exist, as
opposed to the monstrosities that can result from repeated usage of
accept()/fork(). select() also allows you to easily set a timeout value
on each socket. One problem worth mentioning about select(), though, is
that many sockets can be operating in the same process space. You must
be wary of shared resource usage when programming with select(),
whereas with fork(), no such precautions need to be taken. The question
you need to ask yourself before developing a socket based daemon is, as
it usually is, what is the intended use of your program? If it's going
to be servicing many concurrent requests and queueing requests is not
reasonable, using select() is probably the better solution. If not,
using accept()/fork() may prove to be easier.

-dave

[Default User]

dave windsor wrote:

That may be true, but the true power of select() is seen when multiple sockets are in use;

Please learn to quote properly on usenet. See the following for
assistance:
http://groups-beta.google.com/group/...9e82ab0843783d

Brian