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

[Joona I Palaste]

Re: Sockets programming

Bonj <a@b.com> scribbled the following
on comp.lang.c:[color=blue]
> 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.[/color]

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

--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"This is a personnel commuter."
- Train driver in Scientific American

[TanKC]

Re: Sockets programming

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


"Bonj" <a@b.com> wrote in message news:34vc73F4do i88U1@individua l.net...[color=blue]
> 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[/color]
from[color=blue]
> 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[/color]
going[color=blue]
> 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[/color]
the[color=blue]
> 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++[/color]
and[color=blue]
> 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).
>
>
>[/color]

[Bonj]

Re: Sockets programming

Ta very much, appreciate it

"TanKC" <kctan73@google .com> wrote in message
news:O7fHyp9%23 EHA.2580@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> 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
>
>
> "Bonj" <a@b.com> wrote in message news:34vc73F4do i88U1@individua l.net...[color=green]
>> 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[/color]
> from[color=green]
>> 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[/color]
> going[color=green]
>> 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[/color]
> the[color=green]
>> 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++[/color]
> and[color=green]
>> 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).
>>
>>
>>[/color]
>
>[/color]

[Gianni Mariani]

Re: Sockets programming


Off topic for comp.lang.*

However, I suggest you look at some C++ libraries for this sort of thing.

e.g. CommonC++ or ACE.

e.g.

http://www.gnu.org/software/commoncpp/docs/refman/html/tcpservice_8cpp-example.html

I wrote that a while back and I would do it very differently today.

Bonj wrote:[color=blue]
> 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).
>
>
>[/color]

[CBFalconer]

Re: Sockets programming

Bonj wrote:[color=blue]
>
> 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).[/color]

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.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[dave windsor]

Re: Sockets programming

Bonj wrote:[color=blue]
> I've been following a socket programming tutorial to make a simple[/color]
TCP[color=blue]
> communication program, seemingly without hitches, it appears to work[/color]
fine.[color=blue]
> However the structure of it is to have a server listening for[/color]
requests from[color=blue]
> a client using listen(), and when one connects, it communicates with[/color]
that[color=blue]
> 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[/color]
for[color=blue]
> requests from multiple clients, and when *any* client connects, it[/color]
can[color=blue]
> communicate with that client. I'm thinking multithreading is[/color]
obviously going[color=blue]
> to be necessary in some form, but basically my questions are:
>[/color]

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 "multiplexi ng" of requests using only a single process.
As always, see select()'s man pages for more information.
[color=blue]
> 1) Can the server use a method similar to that described in the[/color]
second[color=blue]
> paragraph above to communicate with multiple clients at the same time[/color]
on the[color=blue]
> same port, or does it have to use a different port for each client[/color]
that's[color=blue]
> simultaneously communicating?
> My initial hunch tells me that I can - because a web server can do[/color]
it, but[color=blue]
> is there anything special to watch out for such as how it has to[/color]
integrate[color=blue]
> with (2),...
>[/color]

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

-dave

[Jonathan Bartlett]

Re: Sockets programming

[color=blue]
> 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().[/color]

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
----
Learn to program using Linux assembly language

http://www.cafeshops.com/bartlettpublish.8640017

[balto]

Re: Sockets programming


"Bonj" <a@b.com> дÈëÓʼþ news:34vc73F4do i88U1@individua l.net...[color=blue]
> 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[/color]
from[color=blue]
> 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[/color]
going[color=blue]
> 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[/color]
the[color=blue]
> 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++[/color]
and[color=blue]
> 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).
>
>
>[/color]

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

[balto]

Re: Sockets programming


"Bonj" <a@b.com> дÈëÓʼþ news:34vc73F4do i88U1@individua l.net...[color=blue]
> 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[/color]
from[color=blue]
> 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[/color]
going[color=blue]
> 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[/color]
the[color=blue]
> 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++[/color]
and[color=blue]
> 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).
>
>
>[/color]

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

[dave windsor]

Re: Sockets programming

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]

Re: Sockets programming

dave windsor wrote:[color=blue]
> That may be true, but the true power of select() is seen when[/color]
multiple[color=blue]
> sockets are in use;[/color]


Please learn to quote properly on usenet. See the following for
assistance:


http://groups-beta.google.com/group/...9e82ab0843783d[color=blue]
>[/color]


Brian