DCC use of connect() and sendto() on FreeBSD

Vernon Schryver wrote:

>>There's nothing sinister in the port. 
>>    
>we don't agree.
>
Never mind. I'm jsut interested in the connect() behaviour. Point
being that that port and distribution tarball behave the same
wrt this problem.

> <>more than 4 months old.
>
Same for FreeBSD 4.9-RELEASE :)

>>It seemed that the dcc client code was not consistently disassociating the
>>socket before reconnect or sendto. You can see in my truss output.
>>    
>>
>
>That is not what I see in your truss output.  Instead I see the client
>code trying to disassociate the socket before using sendto().
>  
>
Yes, but it doesn't work. That's the problem.

>I read http://www.rhyolite.com/pipermail/dcc/2004/002388.html
>as proclaiming a problem, a diagnosis, and a fix of changing the
>#ifdef's or the #define.
>  
>
It was actually an observation followed by a question. This question:

"My question is: is this the precompiler behaviour that was originally
intended, or have I broken something?"

>One of my pet peeves is the widely held notion that `truss`, `strace`,
>or other system call tracing is of great value for diagnosing problems.
>When that's all that's available, that's what you use.  However, a
>system call trace is not a substitute for running the application in a
>debugger.
>  
>
Also, running the application in a debugger is not a substitute for
a system call trace.

gdb, strace and truss are all just tools. I have no peeves with
any of them, and I pick whichever shines a light on a problem.

>When I do that on a 4.9-RELEASE system, a line from that `netstat | grep`
>pipeline changes from the following at the start of disconnect():
>    udp4     124      0  calcite.3683       avas.cnc.bc..6277  
>to the following after disconnect() returns:
>    udp4     124      0  *.3683             *.*                
>
>Given your `truss` output, I'd be surprised if the breakpoint in
>disconnect() were not hit.
>  
>
Yes, breakpoint hit, socket still bound after completion of disconnect()

udp4     124      0  203.117.131.34.1980    194.109.153.82.6277

I had actually been down this path days ago. I found that If
I change the definition of DCC_UDP_DISCON, in the FreeBSD case to:

#define DCC_UDP_DISCON  sizeof(ctxt->conn_su)

Then the disconnects seem to work. Just as my test code did.

connect(0x4,{ AF_INET 194.109.153.82:6277 },16)  = 0 (0x0)
sendto(0x4,0xbfbfda08,0x28,0x0,0x0,0x0)          = 40 (0x28)
connect(0x4,{ sa_len = 16, sa_family = 0, sa_data = { 0x18, 0x85, 0xc2,
0x6d, 0x99, 0x52, 00, 00, 00, 00, 00, 00, 00, 00,,28) ERR#22 'Invalid
argument'
sendto(0x4,0xbfbfda08,0x28,0x0,0xbfbfc7b4,0x10)  = 40 (0x28)
sendto(0x4,0xbfbfda08,0x28,0x0,0xbfbfc814,0x10)  = 40 (0x28)

Exuse my use of truss. I find that it concisely shows the socket
operations that I want to see. How to do easily in gdb?

That discovery was the reason for my posting the original question.
I saw that DCC_UDP_DISCON is being used as a precompiler condition,
and also as an argument to connect(). I could not determine the
intent of the disctintion between a value of 0 for 'BSD and the
size_t value for Linux. The size_t value seemed the only correct
one as a third argument for connect().

I guessed that perhaps the 0 value was meant to disable the
use of connected sockets (didn't notice the default of the case)

Hence my original post and question. I was trying to figure out
what was intended. That question again:

"My question is: is this the precompiler behaviour that was originally
intended, or have I broken something?"

-Jamie