I have a series of hardware devices that I'm connecting to create paths through. I have some sanity checking to make sure if potential paths are valid and will do what is intended, but to do it properly I need to know what device is the source of the path, and other information from that soruce.

Once everything is set up I can infer the source by following the path backwards. However, when I first boot up and infer state, and when I send a request in-parallel to multiple devices, I may get connections out of order; so that I can't trace my connections back to the source because I know that connection A and C exit, but am not yet aware of B so I can't trace C back to A yet. This means it's hard to do the error checking right when I add the connection.

My question is how do I do my sanity checking? I have three options, none of which I entirely like

1) trust I do my job right and no bad requests are made

2) try to store the source with each connection when it's created, so I can skip straight to the source for logic checking without tracing the path backwards. This can be done in theory, but I'm afraid that I'm now having to trust that when my pathing logic says something is the source it's right and that source will never change, as well as having logic for inferring source when connections come from the hardware and generally it seems potentially inelegant to maintain.

3) try doing sanity checking as soon as I have a full path (when I add B I now check that B and C are both good), the problem here is that throwing an exception in device B to report an issue with connection made on device C seems...confusing.

4) make connections without validating their sanity, but have someone else in charge of doing a sanity check after all the paths are hooked up (or immediately before)?

1 Answer 1


Use a custom header to enumerate and calculate the number of connections received versus the number of connections expected. For example:

UDP (User Data Protocol) on the other hand is a much simpler technique for delivering data packets. It just adds a header to the data and sends them to its destination, regardless whether that node exists or expects data. UDP does not guarantee that packets arrive, nor does it ensure they arrive in the order they were sent. If packets are transmitted between two networks using different paths they can arrive in a wrong order. It's the application that has to take care of that. However, for applications needing fast transfer without overhead for data that is still usable even if single packets are missing or not in order, UDP is the protocol in choice. Most voice and video streaming applications therefore use UDP.

RFC 7016 describes such an implementation:

Independent flow sequencing allows a sender to prioritize the transmission or retransmission of the messages of one flow over those of other flows in a session, allocating capacity from the transmission budget according to priority. RTMFP is designed for flows to be the basic unit of prioritization. In any flow, fragment sequence numbers are unique and monotonically increasing; that is, the fragment sequence numbers for any message MUST be greater than the fragment sequence numbers of all messages previously queued in that flow. Receipt of fragments out of sequence number order within a flow creates discontiguous gaps at the receiver, causing it to send an acknowledgement for every packet and also causing the size of the encoded acknowledgements to grow. Therefore, for any flow, the sender SHOULD send lower sequence numbers first.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.