From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 21 Mar 2012 16:27:09 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <011b9189eff1a19b0e074faf782dd598@coraid.com> <10d878ecf07027f04938fb4353c8b080@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Regarding 9p based "protocols" message framing Topicbox-Message-UUID: 6d8b228c-ead7-11e9-9d60-3106f5b1d025 On Wed Mar 21 16:11:41 EDT 2012, yarikos@gmail.com wrote: > >> Perhaps initially: over an IP network, 9P used to run over IL. > > > > still does, including on the system i'm sending this from. > > > > What advantages does it have over TCP? Does it worths the effort of > tailoring it back in, esp. for a fossil/venti site? it takes maybe 10 minutes to put it back in. 9atom has il still, since i still use it. i never took it out. i see why one would want to eliminate il and go all tcp, but il is simplier and has no problems that bother me operationally. also there are some fine points of the argument where i have a different opinion than some. of course i may also be motivated by not wanting to put tcp in the file server. ymmv. (in fact, i'd go further than il. why do we need the ip in il?) tcp otoh has a handful of bugs that bite me now and again. the biggest current one is that there appears to be a bug in the implementation that triggers a condition that looks as if nagle is disabled for some connections and early bytes in the window are missing. (infinite resequence queue, full of tinygrams.) this crashes boxes when the run out of kernel memory. i've worked around this by limiting the resequence queue to a reasonable (scaled with the window) number of packets as well as bytes. clearly this is just a hack. but until the trigger for this condition is understood, it'll have to do. - erik