Re: Socket "bind" isn't working for me
Re: Socket "bind" isn't working for me
- Subject: Re: Socket "bind" isn't working for me
- From: Justin Walker <email@hidden>
- Date: Sun, 24 Apr 2005 10:50:56 -0700
On Apr 24, 2005, at 0:32, Cameron Kerr wrote:
On 24/04/2005, at 10:34 AM, Justin Walker wrote:
Ok, but whats wrong with that? In the Windows (which is
remarkebly similar to UNIX sockets), their bind can bind to more
then one address...
[snip]
If you want to re-bind a socket, you must first close that socket,
then create a new socket and bind. This would mean that you may end up
with a different file descriptor.
If you want to listen on multiple addresses, then you should be using
multiple sockets and multiplex them using select() or poll().
AFAICT, the OP wants to *send* to multiple addresses, and is confusing
binding with specifying the destination address.
Another thing I didn't mention in my earlier posting was that I was
also setting my
SocketOpt to SO_REUSEADDR and SO_REUSEPORT respectively.
This doesn't allow it to rebind a port. Rather, it is allows you
ignore if an address is in use. This is used for servers so they
reclaim a port after crashing or restarting.
Correct, and worth underlining.
The bind() error is the fundamental issue for you. It turns out that
the man page is not completely correct. The call also returns EINVAL
only (AFAICT) if the socket descriptor you pass in isn't really a
socket descriptor, or if there is another problem with the sockaddr
structure you pass in.
Shouldn't you get an ENOTSOCK if you pass in something that isn't a
socket? That's what the manual page states. In my experience teaching
this stuff on Linux, it was most easily debugged using strace, which
shows quite nicely what is being passed to bind(). In Mac we have
ktrace and kdump, but the output is really not as useful as strace's,
unless you want to process the output.
Correct again. I misread the code; ENOTSOCK is the error code one gets
if one uses a non-socket file descriptor in a socket API. EINVAL shows
up if the socket structure doesn't contain the information needed to
get a protocol control block or if the sockaddr argument is bogus
(i.e., the value "&sockaddr" is not in the process's address space) or
is otherwise malformed.
In this case, I'm pretty sure that EINVAL is due to the fact that the
OP does not initialize the sockaddr length field ('sin_len').
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for General Semantics
--------
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden