Re: connect(2) for UDP

Peter Deacon wrote:
> 
> bind()
> sendto()
> select() for response
> 
> The select will wake on either the expiration of the timer, data to be 
> read or a failure hint if it turns out nothing was listening on the port
> 
> from the previous sendto()

http://www.opengroup.org/onlinepubs/007908775/xsh/select.html

Huh.  I was going to say that can't work because POSIX says select(2)
can't return ECONNREFUSED or any other ICMP-like error.  But looking at
read(2) and recv(2), I find the same thing.  Poring over Stevens's books
last night, I couldn't find anything definitive either.  The only code
that works is nonstandard and undocumented.  What a mess!  

I think I'll give that a try and hold my thumbs.  

Frediano Ziglio wrote:
> - server reply from a fix interface (netstat say sql browser bind at
> any:1434)

OK, so we can't use connect(2), as you say.  My servers apparently have
only one interface.  Works for me!  :-0

> - using bind have a security problem (SELinux or a firewall can refuse
> the bind) 

That's OK with me.  We had a problem only this week where someone couldn't
even write to a port with SELinux.  Setting up the machine to allow normal
operation is, um, normal.  

We can always fallback to the current logic if bind fails with EACCES. 
But we should use an exponential backoff.  

> but when you send a packet kernel set the output port and do
> a sort of bind (you can understand it calling getsockname)

	???

> - using connect filter packets from server so in the case of more
> interfaces in server you lose the reply

Right. 

> I think it would be better to require all instances so
> server always reply and in case of missing instance
> tds7_get_instance_port return suddently.

Hmm?  It doesn't matter what the request is, whether we ask for one
instance or all instances.  Either way, we're looking at success, timeout,
or ECONNREFUSED. 

--jkl