0

This is strictly in the context of Unix Datagram Sockets: family = AF_UNIX/AF_LOCAL type = SOCK_DGRAM

Does the following look correct for a scenario where a client sends message to server ? Server send to client not required as of now.

  1. Listening/Server socket:

    1.1. Create socket using socket()

    1.2. bind() to a file path

    1.3. recv() or recvfrom() or recvmsg() or read() which'll be blocking by default unless specified via fcntl().

  2. Client socket:

    2.1. Create socket using socket()

    2.2. bind() to the file path in 1.2. This throws EADDRINUSE that address already in use. If connect() is used instead then it results in EPERM operation not permitted.

    2.3. sendto() or sendmsg() or write()

  • Does connect() internally do bind() ? If not then what difference will it make if at 1.2 we do a connect() instead of bind() ? – hznut Feb 6 '15 at 3:51
1

Your listening/server socket logic looks correct but for the client socket:

bind() to the file path in 1.2. This throws EADDRINUSE that address already in use.

...naturally, because the listening socket has already claimed that address.

The client socket would normally want to connect() to the path on which the listening socket is listening.

If connect() is used instead then it results in EPERM operation not permitted.

I'm not sure why you would get that error. I was thinking a permission problem, but permission problems seem to result in EACCES, not EPERM. Try without using connect()? If you omit connect() for datagram sockets this means you have to use sendto() to specify the destination address for every packet. You cannot use send() or write() which expect the destination address to have been preselected using connect().

  • Read the description for EPERM which mentioned something about broadcast. For the client, I tried to do a setsockopt() with SO_BROADCAST option before doing connect() (after 2.1 before 2.2) but same EPERM error. – hznut Feb 6 '15 at 2:25
  • I know, I read that too. But I figured you weren't trying to do broadcasting. In fact I don't even know if broadcast sockets have any meaning at all in the UNIX domain. So that case is not applicable. Which is why I can't think of why you are getting that error. – Celada Feb 6 '15 at 2:32
  • Suppose step 1.1 for server resulted in a file descriptor fd=39. Now for my client, step 2.1 generates a new file descriptor (!= 39). Then client uses this fd (!= 39) in step 2.2 for connect(). Is this correct ? OR should the client use fd=39 ? – hznut Feb 9 '15 at 22:47
  • The client and server are presumably in different processes, so comparing the numeric values of file descriptors between them has no meaning. The receiver socket created at 1.1 and the sender socket creates at 2.1 may or may not have the same numeric value, 39 or otherwise. If the two are in the same process then of course the two different sockets cannot have the same file descriptor number... but then why are you using sockets to communicate inside a single process? – Celada Feb 10 '15 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.