3

I was seeing EADDRNOTAVAIL errors in connect() calls. I dig deeper found that naming of sockets were being done of over zero ip addresses . See following where both calls were sucessful:-

setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *)&y, sizeof(y)); /* y is int with value 1 */

bind(s, (struct sockaddr *)lockaddr, sizeof(rtinetaddr_tp));

where 

lockaddr={.sin_family=2, .sin_port=0, .sin_addr={.s_addr=0}, .sin_zero=""}

This, I found in RH site and also I have the same kernel.

My question is what if I remove doing any bind() at client side of the application? Will that be a quick cure OR will lead to any disaster?

Other way I have running sample programs without bind at client. But the app I am talking about that establishes hundreds of connections. So what may happen in worst case?

Akaks
  • 461
  • 3
  • 21
  • 1
    OT: Shouln't this `bind(*s, ...` be `bind(s, ... `? From the call to `setsockopt(s, ..` I conclude `s` is an `int` and not an `int *` which needs to be dereferenced before using it. – alk Feb 14 '14 at 11:27
  • Thanks that was mistake and have edited – Akaks Feb 14 '14 at 12:29

2 Answers2

2

Binding to a zero address is the same as binding to INADDR_ANY (which is defined as zero). This means you can make a connection on any local IP address (server side) or use the egress interface IP address (client side). This is quite normal.

abligh
  • 24,573
  • 4
  • 47
  • 84
  • yes i saw that is normal thanks but Is there any chance of invalid address binding at client if server is too much busy in making thousand of connections – Akaks Feb 14 '14 at 09:54
  • Given you `bind()` to 0:0, removing that line will probably make no difference. I say probably because technically you are telling it to use the `AF_INET` as opposed to `AF_INET6` address family (the `sin_family=2`). However, on every networking stack I know, you'd have had to have created the socket with `AF_INET` in the first place, so you'd merely be protecting yourself against a socket being created with the wrong address family. However, I don't think removing it will help either, as it's the server that's busy here so even a microsecond's performance increase client side won't help. – abligh Feb 14 '14 at 13:52
  • I think the problem might actually be the line above. `SO_REUSEADDR` is normally only used server side. Using it client side would appear, from the docs, to allow the port to be reused. If connecting to the same server, I can't see how the server can disambiguate tcp sessions. Unless you have a good reason for this, I'd remove it. See http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t (first answer, under Linux) for why you don't get the normal `SO_REUSEADDR` protection *client* side. – abligh Feb 14 '14 at 14:04
1

If you are not interessed in using any particular address:port on the client side, the calls to bind() aren't necessary.

The Kernel will chose the suitable interface and a random port to establish the outgoing connection initiated by the client's call to connect().

alk
  • 69,737
  • 10
  • 105
  • 255
  • still why that is being failed `bind()` is my concern and without `bind()` no problem occured even in 3000 connection per hour – Akaks Feb 14 '14 at 12:36
  • 1
    @Akaks: The call to `bind()` may have failed because the Kernel kept it loked from a previous connection. You could avoid this by setting the option `SO_REUSEADDR` on the socket prior to using it (`setsockopt()`). However a client connecting 3000 times per hour connects less then 1 time per seconds, which is not much. All you really have to take care of that each and every socket gets `close()`ed if not used anymore, as the number of available file-/socket-decriptors is limited by the system. – alk Feb 14 '14 at 12:44