Florian Westphal wrote: > In situations where the loss rate is high it is likely that > all TIPC packet types are affected evenly. > In this case it is better to just send (small) fake-acks for > the source-dropped messages instead of doing complete > re-sends (which might delay other retransmits). What do you think? > > Anyway, guess its time for me to read the packet > retransmission code 8-) > > Florian
I don't think it is possible to deal with the retransmission issue by sending just an acknowledgement (or pseudo-acknowledgement) instead of a complete message, since the receiver requesting the retransmission may be a "classic" TIPC 1.5/1.6 node that needs to receive a message with the correct sequence number in order to be satisfied. So sending a 40 byte, header-only message is probably the best we can do. Jon Maloy had previously suggested modifying TIPC's link protocol so source droppable messages are sent out-of-band (i.e. without sequence number information), but this would involve a more substantial change to the link protocol that would affect both ends of the link. We may still want to go this route in the future, but I'm trying to see what can be done in the short term to address the performance concerns that have been raised by numerous TIPC users ... Regards, Al ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
