Sockets programming

B

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).
 
T

TanKC

Yes.. You can have a server that listens at a desired port for
multiple-clients and communicates using that same port. If you are using
blocking socket, you will have to spawn a worker thread to handle each
client connection.

You probably want to take a look at the following article about blocking and
non-blocking socket :

http://www.developerfusion.co.uk/show/28/8/

TanKC
 
J

Joona I Palaste

Bonj <[email protected]> scribbled the following
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.

Neither C or C++ has any socket, TCP, or other networking support
whatsoever. The fact that you are cross-posting to
microsoft.public.vc.language looks like you are using Microsoft
Windows. I advise therefore to ask on
comp.os.ms-windows.programmer.win32.
If, by any chance, you are using Unix, ask on comp.unix.programmer.
 
B

Bonj

Ta very much, appreciate it

TanKC said:
Yes.. You can have a server that listens at a desired port for
multiple-clients and communicates using that same port. If you are using
blocking socket, you will have to spawn a worker thread to handle each
client connection.

You probably want to take a look at the following article about blocking
and
non-blocking socket :

http://www.developerfusion.co.uk/show/28/8/

TanKC
 
C

CBFalconer

Bonj said:
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 as
well as windows, (the only thing seemingly different in linux
seems to be that it has different includes and doesn't have to
call WSAStartup).

You are way off topic for c.l.c, and probably for c.l.c++ also,
both of which deal only with the portable ISO standardized
languages (which are not the same). The standard languages do not
contain sockets, multithreading, etc. You should read a newsgroup
for a while before posting into it. You should also set followups
to one group when initially posting a cross-posted inquiry.
 
D

dave windsor

Bonj said:
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:

Yes, more than one way exists to do what you're describing. You could
call listen() and fork on each accept(), or you could use the select()
system call. Forking on accept() generates overhead on process
creation/switching and is generally more cumbersome than using
select(). select() blocks and waits for input/output from user defined
file descriptors. When input/output arrives on one of these file
descriptors, select() returns the file descriptor in question, allowing
for efficient "multiplexing" of requests using only a single process.
As always, see select()'s man pages for more information.
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),...

Yes, call the setsockopt() function with the SO_REUSEADDR parameter
set.
setsockopt(SOCK, SOL_SOCKET, SO_REUSEADDR,1)

-dave
 
J

Jonathan Bartlett

Yes, more than one way exists to do what you're describing. You could
call listen() and fork on each accept(), or you could use the select()
system call. Forking on accept() generates overhead on process
creation/switching and is generally more cumbersome than using
select().

Honestly in modern UNIX systems fork()ing doesn't have that much
overhead. It used to be that the entire process space had to be copied
to the new process, but now the page tables are simply marked
copy-on-write, and no actual copying of pages takes place except when
changes occur.

Jon
 
B

balto

Bonj said:
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).

There are several ways to do that without multithreading.
You can use select in linux and WaitForMultipleObjects in windows.
 
B

balto

Bonj said:
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).

There are several ways to do that without multithreading.
You can use select in linux and WaitForMultipleObjects in windows.
 
D

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
 

dll

Joined
Sep 2, 2006
Messages
1
Reaction score
0
Linux socket select option

My Problem is somehow similar.
My main worry is usage of excess memory by POSIX threads.
1. I implemented BSD sockets on Linux socket server (mingwC++).
2. I implemeted pthreads to handle threads...(API for which are controlled by
BSD sockets....socket,bind,listen,accept,recv,send)...After intialization of
sockets(socket,bind,listen,accept),theads are prepared who handle
recv,send from socket.
2.1.In creation of thread a TLS is used....(which handles send,recv
operations).
2.2.Then I keep on joining POSIX threads(created earlier).
2.3.Though I keeps on increasing threads(but memory usage of Linux system
also!)
But as soon as mem usage crosses 3-4%, module stops.

So to overcome this problem, I was going thru web. So at last I came to conclusion that I must use 'select(...)' instead of increasing threads nor pthreads.

Though I have not implemented it yet, but I think that this model must work.
Any suggestions are welcome.
dll
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top