Allow endpoint queues to be injected
- Dominant language
- Go
- Stars
- 19.3k
- Forks
- 2k
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 264
Description
Spun off from #1509 which changed `Read` and `Write` to operate on interfaces.
We may need a deeper rethink of the tcpip.Endpoint API to address longstanding integration issues with Fuchsia. In particular, Fuchsia currently uses a pair of loops to shuttle bytes and signals between a zircon socket and the tcpip.Endpoint. This is necessary because networking is implemented in userspace in Fuchisa, meaning the networking implementation cannot read applications' memory:
```
+-------------+ +-----------------------+ +----------+
| Application | --- | Kernel-managed socket | --- | Netstack |
+-------------+ +-----------------------+ +----------+
```
This results in odd behaviour such as certain errors being first observed and consumed by these loops (e.g. ECONNRESET), preventing retrieval by getsockopt(..., SO_ERROR) without additional work to cache those errors in the integrator. It would be better to teach tcpip.Endpoint (stream endpoints in particular) about externally furnished buffers, which would address this problem.
There are other problems that emerge from this double-buffering, some of which are enumerated in code comments in Fuchsia: https://cs.opensource.google/fuchsia/fuchsia/+/main:src/connectivity/network/netstack/fuchsia_posix_socket.go;l=1857-1892;drc=0a7cdc72620f83c534154bb8e4fcd22cbfaa6252.
I don't yet have a specific interface to propose, but the general idea would be to pass a value of that interface type into `NewEndpoint` and remove `tcpip.Endpoint.{Read,Write}` in favor of interactions with that interface. That would allow Fuchsia to furnish an implementation of send and receive queues using its kernel primitives.
Contributor guide
Assessment
This issue has not been assessed yet.