If i get around to making a V2 of this router, I'll define the [optional byte] to be the sender's IP.
With this information, It would be reasonable to make a more robust router design, one with a timeout xD
if the router waits too long to send a packet, I could then have it timeout and return a 'could not send' packet back to the original sender. The router would generate its own 'return' IP which would have a 11 pair that corresponds to the tree level where the timeout happened. This also means that error reports won't bounce back and forth between non-clients as two successive timeouts would result in sending to a 11 address which will be deleted :O
Armed with the debug info, one could more easily find broken routers and fix large networks with not much hassle!
If i made this, the protocol would be backwards compatible with the current design too which is nice.
EDIT:
Oh you could also opt out of error reports by setting your return IP to include a 11 pair. That might be handy for some people.
With this information, It would be reasonable to make a more robust router design, one with a timeout xD
if the router waits too long to send a packet, I could then have it timeout and return a 'could not send' packet back to the original sender. The router would generate its own 'return' IP which would have a 11 pair that corresponds to the tree level where the timeout happened. This also means that error reports won't bounce back and forth between non-clients as two successive timeouts would result in sending to a 11 address which will be deleted :O
Armed with the debug info, one could more easily find broken routers and fix large networks with not much hassle!
If i made this, the protocol would be backwards compatible with the current design too which is nice.
EDIT:
Oh you could also opt out of error reports by setting your return IP to include a 11 pair. That might be handy for some people.