-
Notifications
You must be signed in to change notification settings - Fork 221
Design model
picoTCP internal design follows the Petri net model to transfer the frames among modules using intermediate queues. All the frames though, are moved across modules by reference, to minimize the number of copies down to the strict necessary amount. A frame entering picoTCP from the socket interface or from a device driver, or being internally generated by one of the modules is in general placed into a queue where the next module can process it. Transitions are clocked by the single module activity, which is periodically scheduled by the stack.
Each module can keep a reference copy of the frame for later use. An example of this is the TCP socket queue, which needs to keep a copy of the segments it sends until the frame containing the segment is acknowledged by the remote endpoint. Usage count in the frame structure allows each module to discard the frames, facilitating the management of the lifetime of the frames throughout the stack.
More about the internal design:
Questions or remarks? Please contact us!
[email protected] | picotcp.altran.be | Twitter | Facebook
Getting Started
- Setting up the environment
- Testing
- Configuring and compiling
- Running picoTCP on Linux - Deprecated (see setting up)
- Running picoTCP on Windows
Porting
- Build process explained
- Porting the build to another compiler or IDE
- Porting picoTCP to your favorite embedded target
- Porting picoTCP to your favorite Operating System
- Example device driver
Development