Stephens, Allan <[EMAIL PROTECTED]> wrote: > The main points in favour of this change are (in no particular order): > > 1) It should be easy to implement. > 2) It should improve the performance on SOCK_DGRAM traffic by a > non-trivial amount. > 3) It makes the distinction between SOCK_DGRAM traffic and SOCK_RDM > traffic much clearer than it currently is. > 4) The change will inter-operate with existing TIPC 1.5/1.6/1.7 systems, > because it is entirely local to the sending node's link endpoint. > 5) It does not preclude us from adding other mechanisms to improve > performance in the future.
6. These messages no longer sit on the outbound queue and leave more room for other message types. > Please let me know what you think. (Comments from other TIPC folks are > also welcome.) I like this idea. Points 1, 3 and 4 are very good arguments. In fact, i think that 3. is probably the best. 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 ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
