On Friday 11 January 2008 18:10, Robert Hailey wrote: > > On Jan 11, 2008, at 11:40 AM, Matthew Toseland wrote: > > > 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? > > I like this schedule of groupings, but for lack of a point of > reference I can't speak towards the coalescing delays.
Well, at the moment we have a maximum coalescing delay of 100ms, so no message will wait much more than 100ms to be sent, modulo bandwidth limits and packet throttle. We also send messages when we have more than [ MTU - 100 bytes ] worth of data to send. > > What do you mean by delay causing the bandwidth limit to be undershot? > It seems to me that if (for example) the packetTransmitters use the > same master throttle, then packets getting ahead of them would cause a > trivial creep of the send queue, but that's it. I mean can the coalescing delay reduce our bandwidth utilisation? If one connection is maxed out, then no, not for that connection, because there will constantly be packets to send, but if we have data trickling out on various connections, and we always wait 200ms before sending it ... I suppose that's also trivial, because as soon as we have another packet to send we'll send the first one. Okay, you're right, there's no problem here. Are you interested in implementing message priorities? MessageItem and PacketSender are the most relevant classes. -------------- 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/d2b10b3b/attachment.pgp>
