FreeTDS Development Group

["Jackson, Craig (Gale)" <Craig.Jackson AT cengage.com>]

> > This would let us know immediately if port 1434 is reachable, and could
> > reduce our retry loop to, say, three tries.
> >
> 
> Mmmm... from comments
> 
>         /*
>          * on cluster environment is possible that reply packet came from
>          * different IP so do not filter by ip with connect
>          */
> 
> the problem is not that easy... if server has two interfaces
> configured server reply from a single interface so it can happen that
> client ask to an interface with a given IP but server reply from
> another IP, in such situation with connect used recv don't receive
> server reply :( I think we can solve this problem using two sockets,
> one connected and another not connected.

Good point -- we had a server with three IPs on one network, so it could have
3 web server instances each listening on port 80.  The source address of the
SNMP UDP packets would end up being round-robined.

This would have to be tested in an actual setup.  I realize that it will be
common for a SQL Server to be clustered.  Does the multiple-IP case happen
on all such servers?

It's a useful thing when it works.  If it generally doesn't work, then that's
a problem.  But if it only fails some of the time, it would be nice to get
the benefit the rest of the time.  I guess the code could try the connected
socket, and if that fails it could create an unconnected socket.

Craig