Daemon/Client sockets
Eduard Marghidan
I have a few not-so-indepth questions about daemons for you wise ones.
I noticed that if using socket() with the SOCK_DGRAM af type, I can
connect multiple clients to the same daemon. This is nice, as I want
to create a chat daemon that would allow multiple clients to connect and
communicate via the daemon. However, if I use the SOCK_STREAM type, only
one client can transmit info to the daemon. Please correct me if my
perception of this is wrong. I have a book on this subject but it's too
advanced.
My program will require duplex communication via a socket. I don't
want to open two sockets for each client if I don't have to.
1. Should I be able to do this with one SOCK_DGRAM type socket? It seems
I can only do recvfrom on the daemon side, and only "sendto" on the client side.
Should I have to open yet another socket and if so, how do I get it to connect
back to the client to send it data?
2. If I have to use SOCK_STREAM socket, how can I connect multiple clients
to one daemon?
3. A somewhat unrelated question is if I use AF_UNIX instead (for testing
this program on a machine without Network Manager) , how do
I start up the client and daemon without a service or address to connect with?
Would they have to be part of the same program?
It seems the samples' receive and send functions require a destination address,
since they use AF_INET.
4. Evidently, a chat daemon would have to broadcast to a whole bunch of
clients simultaneously. Shouldn't I then be able to use one UDP socket
to send out multiple datagrams?
Thank you greatly for your expert help.
Eduard Marghidan
edu...@qdeck.com
Dongxiao Yue
>I have a few not-so-indepth questions about daemons for you wise ones.
>I noticed that if using socket() with the SOCK_DGRAM af type, I can
>connect multiple clients to the same daemon. This is nice, as I want
>to create a chat daemon that would allow multiple clients to connect and
>communicate via the daemon. However, if I use the SOCK_STREAM type, only
>one client can transmit info to the daemon. Please correct me if my
>perception of this is wrong. I have a book on this subject but it's too
>advanced.
Multiple distinct connections can be made to the same port number,
the scenario is like this:
the server open a stream scoket, after bind an address, it listen() and
accept().
The clients open connection to the address+port of the server, upon
the connection request, the server (in accept() ) get another socket
descriptor ,this scoket has the same property of the orginal one, but
they can be distinguished because the new one is connected to a remote
socket.
The server can use the select() call to find out which socket has data
to be read.
You can use SOCK_DGRAM if you do not care possible errors in the transmission.
>4. Evidently, a chat daemon would have to broadcast to a whole bunch of
>clients simultaneously. Shouldn't I then be able to use one UDP socket
>to send out multiple datagrams?
If you use SOCK_DGRAM, you use sendto() which requires the specification
of the remote socket address, you can sendto many receivers through one
local socket (in a loop).
> Thank you greatly for your expert help.
You are welcome.
Walter Rowe
Eduard> My program will require duplex communication via a socket. I
Eduard> don't want to open two sockets for each client if I don't have
Eduard> to.
You don't have to. For UDP sockets, the recvfrom() call gives you the
address the datagram came from, which you turn around and use in the
sendto() call. For TCP sockets, the accept() call returns the socket
descriptor for you, and you use this in subsequent calls to send() and
recv().
For TCP, you have to build fd_set's of file descriptors and perform
select()'s to determine which one has pending I/O or out-of-band data.
The problem with multiplexing TCP connections in this way is figuring
out how to accept() new connections in the same process in which you
are select()'ing amongst existing ones.
Eduard> 1. Should I be able to do this with one SOCK_DGRAM type socket?
When the server daemon server calls recvfrom(), one of the arguments
returned is the address of the client which sent the datagram. The
server daemon uses this in sendto() to reply. Since UDP sockets are
connectionless and recvfrom() returns the address of the originator of
the datagram, the daemon can multiplex several conversations at once.
Eduard> 2. If I have to use SOCK_STREAM socket, how can I connect
Eduard> multiple clients to one daemon?
For TCP, the sockets are connection-oriented. This means the server
daemon and the client maintain an open channel during the entire
conversation. Therefore, the server cannot wait for connection
requests in accept() AND carry on a dialogue with its already active
clients at the same time. Well it can, but that is a problem with an
elegant solution all its own.
The common practice is for the TCP server to accept() a connection,
fork() a child and then close() the accept()'ed socket. The new child
daemon closes the socket the parent was listen()'ing on, and this new
child carrys on the dialogue with the client. The child daemon
send()'s and recv()'s on the accept()'ed socket descriptor. The
server daemon only accept()'s connections, fork()'s off children and
monitors status.
Hope this helps,
Walter Rowe
--
--------------------------------------------+--------------------------
Walter Rowe, Senior UNIX Technical Analyst | Two ways to do something:
Federal National Mortgage Association | (1) do it right
Voice: (202) 752-3735 | (2) do it over
Email: s5u...@fnma.com | Take pride in your work.
--------------------------------------------+--------------------------
Raja B Daoud
>The problem with multiplexing TCP connections in this way is figuring
>out how to accept() new connections in the same process in which you
>are select()'ing amongst existing ones.
Not a problem really. Select() on all your sockets, the server's and
all the client ones. Use FD_ISSET() to check if the server's socket
is ready, in which case it's a new connection, do an accept() and
add the new client. Otherwise, handle incoming client data/commands.
UDP is unreliable and forces the user to write their own reliable
protocol on top (timeouts, ACKs, sequence numbers, etc...). All this
has already been done with streams, no need to reinvent the wheel
unless it's necessary (e.g. to bypass the limitation on the number of
open file descriptors per process). I don't think this is the case in
a chat server (limited # of concurrent users), so streams will do nicely.
--Raja
Raja Daoud Ohio Supercomputer Center
Trollius Operating System 1224 Kinnear Road
ra...@osc.edu Columbus, OH 43212