• ls tries to walk to empty string (not empty walk!) if you just ls - that is, a file with an empty name, not the local directory.
• cd doesn't seem to handle .., just sending a walk to empty string that fails.
• cd to ".." (with the quotes) fails horribly, as 9pr starts to poke at unknown fids (probably didn't check that things

I'm using a Mac running macOS 10.11.5 and Go 1.7.1. I compiled both 9ps and 9pr. I launch 9ps first and then 9pr.

I am getting this output from 9pr:
dialing :5640
EOF

From 9ps I get this output:
connected 127.0.0.1:50604
dialing :5640 for &{{0xc42005a0e0}}
connected 127.0.0.1:50605
dialing :5640 for &{{0xc42005a230}}
connected 127.0.0.1:50606
dialing :5640 for &{{0xc420114000}}
connected 127.0.0.1:50607
dialing :5640 for &{{0xc420114150}}
connected 127.0.0.1:50608
dialing :5640 for &{{0xc4201142a0}}
... (for quite some time)
error creating session
error creating session
error creating session
error creating session
error creating session
error creating session
error creating session
error creating session
... (also, for quite some time)

I'm not entirely sure why 9ps is dialing, but I've only just started exploring this project.

From our Docker for Mac bugsnag error: panic·unknown tag received

Stack trace

panic unknown tag received 
    /usr/local/Cellar/go/1.6.2/libexec/src/runtime/panic.go:481 panic
    .../vendor/github.com/stevvooe/p9p/transport.go:173 (*transport).handle
    .../vendor/github.com/stevvooe/p9p/transport.go:41 newTransport

Couple of places where the p9p library is used:
https://github.com/.../blob/master/v1/abstractions/watch.go
https://github.com/.../blob/master/v1/abstractions/client.go
https://github.com/.../blob/master/v1/docker_proxy/volumes.go

go-p9p isn't using Go modules. An update to make this a go module would be much appreciated.

The current tag allocation algorithm is "hope++". We need to handle collisions against outstanding requests, rollover and exhaustion.

Currently, circleci build is failing due to the use of Go 1.6 in circle ci.

We'll have to upgrade or specifying a build configuration for this to work.

Expected behavior

client.Read should have the same semantic as an io.Reader when reaching the end of a file.
RRead does not contain an error code, but if its count is 0, we should assume we reached the end of file and return either (0, io.EOF) or (0, io.UnexpectedEOF)

Current behavior

Reading from the EOF, returns (0, nil)

Errors when writing messages are handled as non-fatal at the current state, letting the client make the decisions. A failed write is only okay if no data was written - if any data was written, the protocol is trashed and the connection must be let go. If the error is not handled as fatal, and another write is made (could have been queued already), the half-written message + the new message might be read as a valid message by the server which will then do something unexpected, such as responding to a tag the client never used, or writing random data to fids.

In the following piece of code

// Constants for use in Qid to indicate resource type.
const (
    QTDIR    QType = 0x80 // type bit for directories
    QTAPPEND       = 0x40 // type bit for append only files
    QTEXCL         = 0x20 // type bit for exclusive use files
    QTMOUNT        = 0x10 // type bit for mounted channel
    QTAUTH         = 0x08 // type bit for authentication file
    QTTMP          = 0x04 // type bit for not-backed-up file
    QTFILE         = 0x00 // plain file
)

only the first constant has type QType. The other constants are untyped/will default to int when used. Constants only "inherit" the previous constant's type if no explicit value is assigned.

In its current implementation, go-p9p processes each incoming request in its own goroutine, and doesn't wait for their completion before processing subsequent requests.

This breaks the assumption in 9p that requests are processed in order, and that if request B happens after request A, B will observe the effects of A. For example, clunking a file makes it valid to reuse the fid; however if these two operations happened in the reverse order, it'd be a protocol error. Since go-p9p just fires-and-forgets goroutines for requests, no order exists.

9p clients are permitted to send multiple requests, but these are expected to be linearized and executed in order, and the bug in go-p9p is only evident with clients that do this, and under high loads. As far as I am aware, the Linux's 9pnet driver doesn't send multiple outstanding requests, but 9pfuse in plan9ports does.

While there is room for some concurrency, it isn't as trivially implemented as the faulty approach. One could decouple request parsing from request execution (c.f. Instruction Fetch and Instruction Decode in CPUs), or employ dependency analysis to execute requests that are independent of each other concurrently.

Finally, the presence of concurrency was surprising, as it isn't clearly documented. People may not expect methods on a Session to be executed concurrently.

There are several instances of:

if err != nil { return nil } 

In channel.go, line 230 :)

Hey,

I'm trying to figure out how to use this library, and I'm having some trouble. I've gotten 9ps to run, but I can't get anything to connect to it. If I run 9pr (or try to mount from a VM), I get something like this:

./9ps
connected 127.0.0.1:59200
dialing :5640 for &{{0xc8f1269b90}}
connected 127.0.0.1:59201
dialing :5640 for &{{0xc8f1269c70}}
connected 127.0.0.1:59202
dialing :5640 for &{{0xc8f1889340}}
connected 127.0.0.1:59203
dialing :5640 for &{{0xc8f1889420}}
connected 127.0.0.1:59204
error accepting: accept tcp [::]:5640: accept4: too many open files