[Serdev] TCP Blocking Connect issue

[Andrew Mee]

It seems your assumption is right!

Client Logs in.
serctl ul show support at 192.168.2.253
<sip:192.168.2.11:10227;transport=tcp>;q=0.00;expires=3546

Crash Client!!

 serctl ul show support at 192.168.2.253
<sip:192.168.2.11:10227;transport=tcp>;q=0.00;expires=3457

Restart Client

serctl ul show support at 192.168.2.253
<sip:192.168.2.11:10227;transport=tcp>;q=0.00;expires=3403
<sip:192.168.2.11:14858;transport=tcp>;q=0.00;expires=3585

Ok the question now if the TCP connection cannot be made should it 
delete the not available connection and then try the next connection... 
or...
Should perhaps register delete existing entries and create new ones?

Thanks

Andrew

Jiri Kuthan wrote:

>At 01:36 AM 8/23/2004, Andrew Mee wrote:
>  
>
>>The TCP connection is available on the UA, why would it not be on the SER, I have no idea...
>>
>>Sorry I'll clarify, perhaps I have been unclear
>>
>>There are no TCP issues with SER, we can make quite a lot of calls for hours on end no problem, until a client crashes.
>>this results in the following (see other emails for more depth):
>>11(14986) ERROR: tcp_read: error reading: Connection reset by peer
>>11(14986) ERROR: tcp_read_req: error reading
>>Ok, we now restart the client at both ends
>>From this point in we have continual TCP issues that result in (see other email for more depth):
>>11(3048) ERROR: tcp_blocking_connect: SO_ERROR (111) Connection refused
>>11(3048) ERROR: tcpconn_connect: tcp_blocking_connect failed
>>11(3048) ERROR: tcp_send: connect failed
>>Now I then restart SER (and leave the clients running)
>>Relog the clients in again
>>And then we have no problems at all until the client crashes and then SER problems reoccur.
>>This is reproducible every time.
>>
>>My theory is that the TCP connections in SER are not being cleaned up properly when they dropped from the client end.
>>This is SER 0.8.14 btw.
>>    
>>
>
>Thanks. I don't preclude this to be error cause despite the fact
>that SER connects (ie it does not fail during attempt to reuse some TCP connection).
>Still, can't it be that the dead UA's contact remain in server's user location 
>database (I suppose it didn't unregister on crash) and incoming requests are
>then forwarded to this dead TCP server? What do you see with "serctl ul show user at domain"?
>
>-jiri 
>
>  
>


-- 
Andrew Mee