[ENet-discuss] ENet ain't what it could be, Was: ENET_EVENT_TYPE_DISCONNECT with peer address == 0 + additional questions
Adam D. Moss
adam at gimp.org
Tue Jul 4 23:42:51 PDT 2006
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
More information about the ENet-discuss
mailing list