4

This is really basic but I am blanking right now.

I have a daemon process and would like to have multiple clients be able to talk to it. I would like a client to be able to start up and then using a shared library, essentially 'register' with the daemon process. The daemon process would spawn a thread off for this new client and provide a communication pipe between the client and new thread.

I am thinking a unix datagram socket as a 'registration channel' for all clients to use initially and then switching over to a client-specific channel but then cannot figure out how I create unique names for the new datagram sockets without setting them up a priori.

  • Server and clients are on same machine, prefer to use datagram sockets to not have to deal with breaking up the stream into packets.
  • Will be sending (very) high rate small messages back and forth.
Jonas
  • 121,568
  • 97
  • 310
  • 388
RishiD
  • 2,098
  • 2
  • 26
  • 24
  • 3
    I think you don't need anything special. Single domain socket can accept multiple clients, just start communicating on it. This http://stackoverflow.com/questions/9644251/how-do-unix-domain-sockets-differentiate-between-multiple-clients might be a duplicate. – MK. Dec 04 '12 at 21:39
  • I can't use one single socket to talk to multiple clients right? I would still have to build some negotiation protocol to setup a secondary socket to allow a server thread only talk to a single client. – RishiD Dec 04 '12 at 22:45
  • I think every accept returns a new file descriptor – MK. Dec 04 '12 at 23:02
  • That is only for (AF_UNIX, SOCK_STREAM) sockets not DGRAM Which would force me to add a header to my messages and then have to do break up the stream into packets in the receive code. Unix datagram sockets have to have a name associated with them before binding. – RishiD Dec 04 '12 at 23:06
  • ok, I now understand what you are talking about. I'll take a look at my copy of Stevens. – MK. Dec 05 '12 at 00:42

2 Answers2

4

You can entirely avoid the problem of naming the client sockets, if you wish. Each client can create a connected pair of sockets using socketpair(). The client then sends one of the socket descriptors to the server over your well known "registration channel". The server and client then have a private, connected, unnamed pair of sockets for their communication.

The socket descriptor is sent to the server using sendmsg() and filling in the msg's control message.

These two answers have some relevant info/links:

How would I use a socket to have several processes communicate with a central process?

Sending file descriptor over UNIX domain socket, and select()

Community
  • 1
  • 1
Ted Stockwell
  • 41
  • 2
2

Basically I think you need to compromise and have a 2 stage process with a SOCK_STREAM socket as stage 1 and SOCK_DGRAM as stage 2. So it will be like this:

server:

  1. create SOCK_STREAM socket "my.daemon.handshake"
  2. accept client
  3. send a randomly generated string XXX to the client and close the socket
  4. create a SOCK_DGRAM socket "my.daemon.XXX" and start processing it
  5. repeat (2)

client

  1. connect to socket "my.daemon.handshake"
  2. read to EOF -- get value XXX

  3. start communicating with server on socket "my.daemon.XXX"

  4. profit!!!!

MK.
  • 33,605
  • 18
  • 74
  • 111
  • Yea that is the only scheme I could came up with but it just so 'ugly'. This has to be a relatively common thing in Unix land; I might just bite the bullet and use local STREAMS just for the automatic file descriptor creation per connection. – RishiD Dec 05 '12 at 03:07
  • I dunno. This doesn't strike me as super-ugly. You can always use some higher-level abstraction like RabbitMQ, ZeroMQ or perhaps even dbus. – MK. Dec 05 '12 at 05:29