DoBroadcast=Direct fails to find dbserver on non default port

[MCMartin]

With odbc driver of 11.0.1.2713 I have the situation, that the database server is not found, if I use DoBroadcast=direct in the connection string. Using the same string without the DoBroadcast works.

Reason seems to be that 2 DB servers are running on the attempted machine one on default port 2638 and one on alternate port 49157. The DB server I am looking for is running on the alternate port.

Is this a bug or have I misunderstood the concept of DoBroadcast=Direct

[VolkerBarth]

Does the connect work if you specify the server's port number in the connection string, such as

CommLinks=tcpip(DOBROADCAST=DIRECT;HOST=silver;PORT=49157) demo

?

[MarkCulp · Accepted solution]

When you use the DoBroadcast=Direct connection property you must specify the host and port number that the server is listening on. Another way of thinking of it is that the 'direct' options says 'I know what I am doing; do not do any redirection'. Since you did not specify a port in your connection string the client defaulted to 2638.

As Volker suggested in his comment, if you add the port to the connection string you should be able to connect.

[Breck_Carter · Accepted solution]

Why do you have to specify the port with DOBROADCAST=DIRECT? I thought you just had to specify the host, and SQL Anywhere would do a broadcast to that host.

(however, I only use NONE which does require both host and port, so my actual DIRECT experience is non-existent 🙂

[MCMartin · Accepted solution]

@Mark: Thanks for clarifying this. With your explanation I would suggest to add that to the documentation, currently it gives a different impression:

"With DoBroadcast=DIRECT, no broadcast is performed to the local subnet to search for a database server. Broadcast packets are sent only to the hosts listed in the HOST (IP) protocol option. If you specify DoBroadcast=DIRECT, the HOST (IP) protocol option is required."

[VolkerBarth]

To add to Mark's answer:

I guess the PORT is only needed if the server is not using the default port (2638) - that's a guess, I share @Breck's DIRECT experience:) - From the v11.0.1 docs on SERVERPORT:

If the database server's TCP/IP port number is not 2638, then the server listens to the same UDP port as the TCP/IP port.

In case the client sends a broadcast only to UDP port 2638 by default (which I don't know), it would explain why a server running on a different port would not get that broadcast...