gfwleak/zhangyang-libzt
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated rx/tx doc

Browse Source
This commit is contained in:
Joseph Henry
2016-12-06 14:00:28 -08:00
parent 984f21ddd5
commit c8c80d23b8
1 changed files with 8 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/rxtx.md
View File

@@ -8,42 +8,39 @@ How Data is Sent and Received by an App using the SDK
The **tap service** monitors incoming packets, when one destined for us is detected it notifies the **stack driver** via `put()`. Then `pico_rx()` is called, its job is to re-encapsulate the ethernet frame and copy it onto the guarded `pico_frame_rxbuf`. This buffer is guarded because it is accessed via the **tap service** thread and the **network stack** thread. The **tap service** monitors incoming packets, when one destined for us is detected it notifies the **stack driver** via `put()`. Then `pico_rx()` is called, its job is to re-encapsulate the ethernet frame and copy it onto the guarded `pico_frame_rxbuf`. This buffer is guarded because it is accessed via the **tap service** thread and the **network stack** thread.
``` ```
SERVICE_THREAD
wire wire
put() put()
pico_rx() ---> <pico_frame_rxbuf> pico_rx() ---> <pico_frame_rxbuf>
``` ```
Periodically the stack thread will call `pico_eth_poll()`, this is responsible for reading the frames from the aformentioned RX I/O frame buffer and feeding it into the stack via `pico_stack_recv()`. Periodically the **network stack** thread will call `pico_eth_poll()`, this is responsible for reading the frames from the aformentioned `pico_frame_rxbuf` and feeding it into the stack via `pico_stack_recv()`.
``` ```
STACK_THREAD
pico_eth_poll() pico_eth_poll()
<pico_frame_rxbuf> ---> pico_stack_recv <pico_frame_rxbuf> ---> pico_stack_recv
``` ```
After some time has passed and the stack has processed the incoming frames a `PICO_SOCK_EV_RD` event will be triggered which calls `pico_cb_socket_activity()`, and ultimately `pico_cb_tcp_read()`. This is where we copy the incoming data from the `pico_socket` to the `Connection`'s `rxbuf`. We then notify the ZeroTier tap service that the `PhySocket` (a wrapped file descriptor with one end visible to the application) associated with with this `Connection` has data in the `rxbuf` that needs to be written to it. After some time has passed and the **network stack** has processed the incoming frames a `PICO_SOCK_EV_RD` event will be triggered which calls `pico_cb_socket_activity()`, and ultimately `pico_cb_tcp_read()`. This is where we copy the incoming data from the `pico_socket` to the `Connection`'s `rxbuf` (different from `pico_frame_rxbuf`). We then notify the **tap service** that the `PhySocket` (a wrapped file descriptor with one end visible to the application) associated with this `Connection` has data in its `rxbuf` that needs to be written so the app can read it.
``` ```
STACK_THREAD
pico_cb_socket_activity() pico_cb_socket_activity()
pico_cb_tcp_read() ---> conn->rxbuf pico_cb_tcp_read() ---> conn->rxbuf
setNotifyWritable=TRUE setNotifyWritable=TRUE
``` ```
After some (more) time, the ZeroTier tap service thread will call `pico_handleRead()`, this will copy the data from the `rxbuf` to the `AF_UNIX` socket which links the service and your application. After this point it's up to you application to read the data via a conventional `read()`, `recv()`, or `recvfrom()` call. After some (more) time, the **tap service** thread will call `pico_handleRead()`, this will copy the data from the `rxbuf` to the `AF_UNIX` socket which links the service and your application.
``` ```
SERVICE_THREAD pico_handleRead()
pico_handleRead()x
streamSend(): conn->rxbuf --- conn->sock streamSend(): conn->rxbuf --- conn->sock
``` ```
... After this point it's up to your application to read the data via a conventional `read()`, `recv()`, or `recvfrom()` call.
```
APP_THREAD
read() read()
```
*** ***