A better solution is to poll the tcp buffer size as I mentioned before. The empty buffer insures us that the client received the data. A ping from bip to client would be useful, and I don't remember if it's missing on top of my head. But every two second is overkill and still incorrect as messages can come in those two seconds.
2010/9/15 Fabien Tassin <[email protected]>: > if i understand the code correctly, it seems bip is able to answer to > PINGs from the server or from the client, send PINGs to the server but > it doesn't emit its own pings toward the client. > > What about making bip ping the client on a quite fast pace (such as > ~2sec), or with a user configurable interval & timeout? > > something like this: > > client bip server > | ------ PING X -------> | | > | <----- PONG X -------- | | > | | | > | | <------ PING Y ------- | > | | ------- PONG Y ------> | > | | | > | | ------- PING Z ------> | > | | <------ PONG Z ------- | > | | | > | <----- PING T -------- | > | ------ PONG T -------> | > > (X/Y/Z/T are independent, i.e. no ping relay) > > X, Y and Z are already there. > > T would allow bip to a/ detect much faster than the client is gone and > b/ truncate the backlogs after each PONG (at the time the corresponding > PING was sent) to avoid too many duplicates during replays. > > What do you think? > > /Fabien > > > > -- Arnaud Cornet -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
