[Vortex] hang on quit -- "we still didn't received all replies" over and over

[Jens Alfke]

On 7 Apr '08, at 10:02 AM, Francis Brosnan Blazquez wrote:

> If your application do not trust remote peer you should use
> vortex_connection_shutdown to avoid this kind of problem.

You can't trust _any_ remote peer; not to the extent of allowing it to  
crash or hang your code. Even if you've authenticated it and you know  
you wrote its code, it could still have bugs; and you don't want a bug  
in one place to turn into a tar-baby that locks up anything that  
touches it.

My app's users won't know or care about the BEEP protocol. But if my  
app locks up when disconnecting and has to be killed, they'll file bug  
reports that I have to deal with. :-P

If I call vortex_connection_shutdown instead, that pretty much  
guarantees the channels won't close cleanly, so in the more likely  
case where things _are_ OK, it can introduce problems.

> In the same direction, having a configurable-timeout is not a solution
> because will yield soon or later to the same situation.

Agreed, there is no perfect solution (I think this is isomorphic to  
Turing's infamous Halting Problem.) The typical heuristic used in  
network programming is to follow protocols, but use timeouts in case  
something goes wrong. If my web browser sends an HTTP GET and never  
gets a response, it gives up after a minute and puts up an error. And  
if I quit it, it certainly doesn't hang waiting for the socket to close.

So what I want is basically vortex_connection_close with a timeout.  
99% of the time everything closes down cleanly. In the 1% of the time,  
my app locks up for, say, 30 seconds, then recovers and shuts down the  
connection and quits.

—Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080407/61f727e1/attachment-0001.bin