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

[Francis Brosnan Blazquez]

Hi Jens,

> > Check your listener code to see why over the channel 20 a reply to  
> > MSG 0
> > is still pending. With pending replies the Vortex engine must wait for
> > them before closing (without clearly knowing when those replies will
> > arrive).
> 
> 
> I'll see what's going on in my code, that the message isn't replied to.
> 
> But in general, this means that a buggy (or malicious) peer can, by  
> withholding replies, cause my app to hang forever when closing the  
> connection. I can't allow that (it's a DoS attack.) Could  
> vortex_connection_close be modified to use some sort of timeout?

Ok, I see your point but...

BEEP allows both peers to ensure they won't close any channels unless
both agree. This is a good feature....until some peer start to behave in
a malicious way since an attacker could setup a DOS by simply not
replying...

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

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

In other words, calling to vortex_connection_close, having channels
opened makes your application to implicitly rely on what the remote peer
is going to do. Again this is a nice feature or your worst nightmare
according to level of confidence and the kind of protocol being
developed.

In fact, you don't have to go to the extreme case where a malicious peer
just don't reply; think about a properly implemented peer that simply
denies closing some channel because there are pending transactions. 

In this case, vortex_connection_close will also fail (obviously without
blocking the caller).

In general, trying to close channels and BEEP sessions in a nice way
(calling to vortex_channel_close or vortex_connection_close) is because
your protocol design cares about pending replies and, under that
situation, it is assumed closing channels could fail.

Cheers!

> Jens
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.