I've begun working on the actual program flow to send data through the serial ports seamlessly.

Here is the flowchart I've thought up for the initial design.

It's a big ugly, forgive me. But as you can see from the flowchart, I'm trying to keep the logic between the communicators the same. The only difference between the "client" and "server", is one starts at the "Receive data" stage, and the other starts at the "Read from serial and send packet" stage.

I did a quick implementation of this in a dirty state machine, and here are the issues I've had thus far that I need to look into fixing/improving:

• Currently my serial read function blocks until some data appears on the pty slave port. I need to find a way to make this process time out in order for the flow above to function correctly.
• The time it takes to send a heartbeat packet MUST be smaller than the time it takes for the Receive packet stage to time out. Otherwise one party things he's dropped a packet, but in reality the other party just didn't have any data to send.
• With this system we need to reserve a byte as a command area so we know if a packet is a heartbeat or a retry (duplicate data) so we know how to behave when we get those packets. Because serial sends data by bytes and not bits, this means we're left with 57 bytes in a packet, I only need 2 bits to send my command flags, so 6 bits are wasted.

Other than that, I think this a good basis for my design for v1 of chirppp, once I fix any bugs that rear their ugly head, of course.

If anyone is actually reading these, and likes to minimize program flows in their spare time (not judging), I'd love to hear any ideas on a flow that won't lose or accidentally duplicate packets, or if you spot any problem areas in the flow above, please let me know!