Re: [9fans] Acme Mail editable from address
Quoth pouya+lists.9f...@nohup.io: > I was looking for a way to send emails from different addresses with > Acme Mail, as I use + address suffixes to sort incoming mail and > occasionally need to send emails from the same (e.g. to this mailing > list). Not finding a convenient way, I committed a bad hack to > include an optional From: line in the header of outgoing messages. > It's available at > > 9p.io/sources/contrib/pdt/acme/mail > > in case someone might find it useful (or be kind enough to tell me > this is not the right way to do it). > The ability is useful, but the code to do it would be better placed in upas/marshal. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9469a3ec554967c5-M45b4767d3b572a1f2d04a7b9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Dual dialing/forking sessions to increase 9P throughput
On Wed, Jan 27, 2021, at 11:25, Ethan Gardener wrote: > fcp(1)? You are right, but fcp(1) would only produce multiple parallel read and write messages, I'm talking about a more general approach. fcp is probably a better compromise, though, as ori points out the client can get complicated pretty quickly when trying to solve the problem more generally: On Wed, Jan 27, 2021, at 11:52, o...@eigenstate.org wrote: > This also has some hairy edge cases. For example, > what happens to the actions in the pipeline if one > of the operations fails? Yes, the tradeoff of this pipelining is that the client becomes a lot more complex, but for this specific problem, the client would need to be prepared to receive and discard Rerror messages for each message after the failed one, just surfacing the first error to whatever system call or library function kicked off this sequence of messages. > I think that for this kind of pipelining to be > effective, 9p may need some notion of 'bundles', > where the first failure, short write, or other > exceptional operation would cause all other > commands in the bundle to be ignored. You can get pretty close to "bundles" without changing the protocol by having the client reserve a few bits of storage in the Tag header to group requests in a pipeline together: # Bundle 1, sent at once Twalk tag=0x0100 fid=0 newfid=1 "foo/bar" Topen tag=0x0101 fid=1 O_RDONLY Twrite tag=0x0102 fid=1 data Tclunk tag=0x0103 fid=1 Then the client could use a trie or some similar data structure on the tag of an R-message to get the "state" of a pipeline. > Another issue is that its' difficult to retrofit > this pipelining into the plan 9 system call > interface; when do you return an error from > read(2)? what if there are mutiple Treads? This is a harder problem, I think. What if non-contiguous reads or writes succeed? An mmap()-style API might fare better here, but that comes with its own drawbacks. I don't have a good answer here, but I think since Twrite and Rread messages are elastic it is always better to just send larger messages, increasing msize if necessary. > how do you handle congestion if you can stuff as many 9p packets down > a single connection as possible? There's no packet loss, but you can > end up with very long delays as small reads like /dev/mouse get queued > behind bulk transfers. The problem you describe is analagous to the "buffer bloat" problem. In the lower protocols like TCP it is solved by making the sender aware of the bandwidth delay product and sizing its buffers appropriately. So it could be handled by using a model-based congestion avoidance algorithm like BBR or Vegas, and sending messages out of a prioritized queue, where "interactive" files like /dev/mouse are prioritized. David -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M6e7a64ad95ea27ac3c73a9ac Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Acme Mail editable from address
I was looking for a way to send emails from different addresses with Acme Mail, as I use + address suffixes to sort incoming mail and occasionally need to send emails from the same (e.g. to this mailing list). Not finding a convenient way, I committed a bad hack to include an optional From: line in the header of outgoing messages. It's available at 9p.io/sources/contrib/pdt/acme/mail in case someone might find it useful (or be kind enough to tell me this is not the right way to do it). Pouya -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9469a3ec554967c5-M059a7a0d5e206cd7b9c25ef2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] authoritative source for u9fs?
No the source code differences are pretty vast as well, although right now I couldn't tell you what the main theme of the changes might be. Lucio. On 1/27/21, Ethan Gardener wrote: > On Mon, Jan 25, 2021, at 5:10 AM, Lucio De Re wrote: >> >> PS: The new executable seems noticeably bigger than whatever I used >> previously. Which happens to be the NetBSD "pkg" version >> (/usr/pkgsrc/filesysytems/u9fs). Hmm, the differences are quite >> significant... > > Just checking: Was the old one `strip`ped and the new one not? That's caught > be out before; the symbol table being by far the largest part of some > binaries. > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-M696d655d3b3e6536a3980424 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Dual dialing/forking sessions to increase 9P throughput
I found several of Bryan Ford's ideas interesting as always here, particularly Structured Streams (https://bford.info/pub/net/sst-abs/) and Breaking Up the Transport Logjam (https://bford.info/pub/net/logjam-abs/) On Wed, Jan 27, 2021 at 4:53 PM wrote: > Quoth David Arroyo : > > On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote: > > > It's well-known that 9P has trouble transferring large files (high > > > volume/high bandwith) over high-latency networks, such as the Internet. > > > > From what I know of 9P, I don't think this is the fault of the protocol > > itself. In fact, since 9P lets the clients choose Fid and Tag > identifiers, > > it should be uniquely well suited for "long fat pipes". You could avoid > > waiting for round-trips by optimistically assuming your requests succeed. > > For example, you could do the following to optimistically read the first > > 8K bytes of a file without needing to wait for a response from the > server. > > > > * Twalk tag=1 fid=0 newfid=1 /path/to/somefile > > * Topen tag=2 fid=1 o_read > > * Tread tag=3 fid=1 off=0 count=4096 > > * Tread tag=4 fid=1 off=4096 count=4096 > > * Tclunk tag=5 fid=1 > > > > I'm not aware of any client implementations that do this kind of > > pipelining, though. > > > > David > > This also has some hairy edge cases. For example, > what happens to the actions in the pipeline if one > of the operations fails? > > I think that for this kind of pipelining to be > effective, 9p may need some notion of 'bundles', > where the first failure, short write, or other > exceptional operation would cause all other > commands in the bundle to be ignored. > > Another issue is that its' difficult to retrofit > this pipelining into the plan 9 system call > interface; when do you return an error from > read(2)? what if there are mutiple Treads? > > Finally, there's the problem of flow control; > with 9p, round trip time limits starvation, > at least to a degree. But how do you handle > congestion if you can stuff as many 9p packets > down a single connection as possible? There's > no packet loss, but you can end up with very > long delays as small reads like /dev/mouse > get queued behind bulk transfers. > > There are some programs that try to handle this > for 'well behaved' file systems (eg, fcp(1), > or http://src.a-b.xyz/clone/, but making it > happen in general is not trivial. > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M40bb94bd40d97df72c885f69 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Dual dialing/forking sessions to increase 9P throughput
Quoth David Arroyo : > On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote: > > It's well-known that 9P has trouble transferring large files (high > > volume/high bandwith) over high-latency networks, such as the Internet. > > From what I know of 9P, I don't think this is the fault of the protocol > itself. In fact, since 9P lets the clients choose Fid and Tag identifiers, > it should be uniquely well suited for "long fat pipes". You could avoid > waiting for round-trips by optimistically assuming your requests succeed. > For example, you could do the following to optimistically read the first > 8K bytes of a file without needing to wait for a response from the server. > > * Twalk tag=1 fid=0 newfid=1 /path/to/somefile > * Topen tag=2 fid=1 o_read > * Tread tag=3 fid=1 off=0 count=4096 > * Tread tag=4 fid=1 off=4096 count=4096 > * Tclunk tag=5 fid=1 > > I'm not aware of any client implementations that do this kind of > pipelining, though. > > David This also has some hairy edge cases. For example, what happens to the actions in the pipeline if one of the operations fails? I think that for this kind of pipelining to be effective, 9p may need some notion of 'bundles', where the first failure, short write, or other exceptional operation would cause all other commands in the bundle to be ignored. Another issue is that its' difficult to retrofit this pipelining into the plan 9 system call interface; when do you return an error from read(2)? what if there are mutiple Treads? Finally, there's the problem of flow control; with 9p, round trip time limits starvation, at least to a degree. But how do you handle congestion if you can stuff as many 9p packets down a single connection as possible? There's no packet loss, but you can end up with very long delays as small reads like /dev/mouse get queued behind bulk transfers. There are some programs that try to handle this for 'well behaved' file systems (eg, fcp(1), or http://src.a-b.xyz/clone/, but making it happen in general is not trivial. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-Maff5e0961941062961ff4f2d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Dual dialing/forking sessions to increase 9P throughput
On Mon, Jan 25, 2021, at 10:31 PM, David Arroyo wrote: > On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote: > > It's well-known that 9P has trouble transferring large files (high > > volume/high bandwith) over high-latency networks, such as the Internet. > > From what I know of 9P, I don't think this is the fault of the protocol > itself. In fact, since 9P lets the clients choose Fid and Tag identifiers, > it should be uniquely well suited for "long fat pipes". You could avoid > waiting for round-trips by optimistically assuming your requests succeed. > For example, you could do the following to optimistically read the first > 8K bytes of a file without needing to wait for a response from the server. > > * Twalk tag=1 fid=0 newfid=1 /path/to/somefile > * Topen tag=2 fid=1 o_read > * Tread tag=3 fid=1 off=0 count=4096 > * Tread tag=4 fid=1 off=4096 count=4096 > * Tclunk tag=5 fid=1 > > I'm not aware of any client implementations that do this kind of > pipelining, though. fcp(1)? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M1b4dd6e347d2d00d2cd645d8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] authoritative source for u9fs?
On Mon, Jan 25, 2021, at 5:10 AM, Lucio De Re wrote: > > PS: The new executable seems noticeably bigger than whatever I used > previously. Which happens to be the NetBSD "pkg" version > (/usr/pkgsrc/filesysytems/u9fs). Hmm, the differences are quite > significant... Just checking: Was the old one `strip`ped and the new one not? That's caught be out before; the symbol table being by far the largest part of some binaries. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-M74ae21d6ac07c6d16acab49f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9p.zone: Public 9P Registry Services
On 1/27/21, fge...@gmail.com wrote: > On 1/25/21, sirjofri+ml-9f...@sirjofri.de > wrote: >> Hello all, >> >> we haven't announced it here, I believe, so here it is: >> >> 9p.zone is a public registry service for 9p services, OS agnostic. >> This means, it works for Plan 9, 9front, inferno, basically all 9p >> capable systems can use the registry. The project is public, so it's >> meant for public services and everyone can announce their services in >> this registry. >> >> While the center of 9p.zone is the registry itself (CORE services), we >> also plan to do other services as well (called EXTRA services). This >> services should help others to build great 9p stuff for the community, >> without the need to do everything. For example, we plan to build >> public auth services for free that can be used as a SSO service for >> other 9p services built by YOU. >> >> Furthermore, the old gridchat (from 9gridchan.org, which is basically >> shut down) is also inside this domain (chat.9p.zone). The whole >> 9p.zone will become a new grid system that's free and public. >> >> More information about the registry is available via http://9p.zone . >> Feel free to contribute your public services. >> >> >> sirjofri > > Nice, thanks! > mount -A tcp!registry.9p.zone!registry /mnt/registry worked from > inferno on the day you sent the announcement, but it does not seem to > connect now. Is it supposed to work now? > thanks! > pebkac, it's working fine. sorry -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta99fa16f523b4280-M8efd52a66122142ca8a0402c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9p.zone: Public 9P Registry Services
On 1/25/21, sirjofri+ml-9f...@sirjofri.de wrote: > Hello all, > > we haven't announced it here, I believe, so here it is: > > 9p.zone is a public registry service for 9p services, OS agnostic. > This means, it works for Plan 9, 9front, inferno, basically all 9p > capable systems can use the registry. The project is public, so it's > meant for public services and everyone can announce their services in > this registry. > > While the center of 9p.zone is the registry itself (CORE services), we > also plan to do other services as well (called EXTRA services). This > services should help others to build great 9p stuff for the community, > without the need to do everything. For example, we plan to build > public auth services for free that can be used as a SSO service for > other 9p services built by YOU. > > Furthermore, the old gridchat (from 9gridchan.org, which is basically > shut down) is also inside this domain (chat.9p.zone). The whole > 9p.zone will become a new grid system that's free and public. > > More information about the registry is available via http://9p.zone . > Feel free to contribute your public services. > > > sirjofri Nice, thanks! mount -A tcp!registry.9p.zone!registry /mnt/registry worked from inferno on the day you sent the announcement, but it does not seem to connect now. Is it supposed to work now? thanks! -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta99fa16f523b4280-Mb0c91ed2e6573982806f606f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
