[ENet-discuss] ENet ain't what it could be, Was: ENET_EVENT_TYPE_DISCONNECT with peer address == 0 + additional questions

[Adam D. Moss]

Lee Salzman wrote:
> Adam D. Moss wrote:
>> You have to implement an application-level reliable acknowledgement
>> of disconnect.  Not ideal IMHO, but that's the way it is.
> 
> Feel free to suggest some sensible implementation of synchronous 
> disconnect, taking into account queued outgoing packets in channels, 
> also taking into account incoming packets while these remaining packets 
> are sent out, and any other new packets the host sends out after issuing 
> the disconnect request..
> 
> The more I thought about it, the less I could find a satisfying way of 
> doing it. Say, while the remaining outgoing packets are being sent out, 
> you get new incoming packets. Do you deliver those?  [..] Too
 > many "what if"s.

It seems to me that the remaining chain of 'if's collapses if the
answer to the first question is 'no' -- and dropping further
incoming/outgoing packets seems like reasonable semantics
for a connection that one end has explicitly disclaimed all
interest in.  (However, this could leave the remote end in
a state of uncertainty concerning which of its outgoing
in-flight reliable packets were really processed before the
block came down, but that's the same situation as a ENet
forced-disconnect-due-to-netburp so the app would have to
deal with such uncertainty anyway.)

I guess the question 'what do BSD TCP sockets do?' is
relevant -- I don't have enough experience with the socket
API to know for sure, myself, but I think the socket 'close'
blocks by default until outstanding 'write's are all ack'd.

Cheers,
--Adam