On Friday 11 January 2008 08:34, Michael Rogers wrote: > Robert Hailey wrote: > > Rejecting new > > requests would keep the data-transfer level traffic from being > > starved. > > Yup, that makes sense as long as it also applies to local requests.
Which it does, as of some weeks back. BTW robert, we do have a limit on the number of running requests: the bandwidth liability limits. Now, is there any reason to prioritise different control messages differently? And do we want absolute priorities, or different timeouts (messages will be sent at t+100ms if they haven't been sent already at the moment, we could vary this by type), or both? For example: Group 0: 100ms coalescing timeout. Packet acknowledgments. These need to be sent fairly quickly. Group 1: 100ms coalescing timeout. Various messages with short timeouts, or which we need to send quickly for one reason or another. FNPAccepted FNPRejectedLoop FNPRejectedOverload FNPDataInsertRejected FNPSSKAccepted FNPCHKDataRequest FNPSSKDataRequest FNPRecentlyFailed (can be sent at Accepted time, or later) FNPInsertRequest FNPDataInsert FNPRejectedTimeout (counterpart of FNPDataInsert) FNPSSKInsertRequest FNPSSKAccepted FNPSSKPubKeyAccepted FNPOpennetAnnounceRequest FNPOpennetDisabled FNPOpennetNoderefRejected FNPPing/FNPPong - ???? FNPLinkPing/FNPLinkPong - ???? FNPProbeRequest - ???? FNPProbeRejected - ???? FNPDetectedIPAddress - good to have this arrive soon after connect FNPTime - ditto FNPSentPackets - ditto FNPDisconnect - good to have this arrive quickly as we may be shutting down UOMRequestRevocation UOMSendingRevocation FNPRoutingStatus FNPSwapRequest/Rejected/Reply/Commit/Complete/Rejected - 60 seconds timeout, but IMHO we need these to move fast Group 2: Messages which don't have particularly short timeouts. 200ms coalescing timeout? Or even more? allSent - not very important missingPacketNotification - no short timeout, however we do want it to arrive soonish so we can complete the transfer; maybe include in the next group??? allReceived - important message, 60 second timeout sendAborted - moderately important message, can go each way, 60 second timeout one way FNPBulkSendAborted - long timeout (5min) FNPBulkReceiveAborted - no timeout, dropped on completion FNPBulkReceivedAll - no timeout, dropped on completion nodeToNodeMessage - maybe treat this as bulk? FNPDataFound - long timeout (2min) FNPCHKDataFound - long timeout (2min) FNPRouteNotFound - long timeout (2min) FNPInsertReply - long timeout (2min) FNPSSKDataFound FNPDataInsertRejected - ?? FNPInsertTransfersCompleted - long timeout (2min) FNPOpennetCompletedAck - long timeout (2min) FNPOpennetConnectDestinationNew - long timeout (2min) FNPOpennetConnectReplyNew - long timeout (2min) FNPOpennetAnnounceReply - long timeout (4min) FNPOpennetAnnounceCompleted - long timeout (4min) FNPOpennetAnnounceNodeNotWanted - long timeout (4min) FNPOfferKey FNPProbeTrace - ???? FNPProbeReply - ???? FNPLocChangeNotification FNPRoutedPing/Pong FNPVoid UOMAnnounce UOMRequestMain UOMRequestExtra UOMSendingMain UOMSendingExtra Group 3: Bulk data transfer. 200ms coalescing timeout? Or even more? (note these are all around 1kB, they should all behave similarly to minimize the available data for traffic analysis) 200ms timeout? packetTransmit FNPBulkPacketSend FNPSSKInsertRequest FNPSSKDataFound FNPSSKPubKey When we do decide to send a packet, we should send as big a packet as possible, provided that this doesn't break the timeouts, so usually we would bundle some packet acks, some high priority messages which are past their timeout, some high priority messages which are not past their timeouts, and one big message. Another consideration: can delaying packets for coalescing cause us to grossly undershoot our bandwidth limit? > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080111/06d9a44f/attachment.pgp>
