MASQ-Project
Introduce CORES packages for Ping and PingResponse
As of the writing of this card, there are five structures that can inhabit a CORES package:
Gossip_0v1
NodeRecordInner_0v1 (this is cheating, kind of; see below)
DnsResolveFailure_0v1
ClientRequestPayload_0v1
ClientResponsePayload_0v1
NodeRecordInner_0v1 doesn't completely count because it doesn't go directly inside a CORES package; it goes inside a Gossip_0v1.
But we need to add another, and code to handle it.
It should be a Ping-like packet that is routed to the Hopper of a target Node (this routing logic will be enhanced later, but for this card we should just use the existing routing_engine). When a Node receives one of these Ping-like packets, it should instantly--as quickly as possible, because latency is what we're measuring--send back a Ping response to the Proxy Server of the originating Node.
Whenever a Node communicates, it does so with another Node across a link. Thus, the idea of the isolated latency of a Node may be nice to think about, but it can't be measured unless a Node is measuring its own latency. In every other case, the important concept is the latency of a link, including the Nodes on each end.
Eventually, there'll be a card for figuring out when and where to send a Ping message. For now, put in temporary code that arranges to send a Ping across a link whenever it shows up for the first time in the Neighborhood. Mark the code so that it can be easily located and removed later.
This will require modifying the Neighborhood so that it stores information not only about Nodes in the network, but also about the links between those Nodes. (This will probably be in a different data structure.)
When an originating Node receives a Ping response, it should look up the information it saved about the Ping request and compute a whole-route latency figure, which it should log to the logfile. (Eventually we will do more productive things with the latency figure; for the moment we'll just log it.)
If an originating Node receives a Ping response that it did not solicit, it should log a warning and discard the response.
Note: This card will probably be easier to implement if we postpone it until after Reversal Mode is implemented.
Another Note: Don't put a timestamp in the Ping packet or its response. On the one hand, timestamps don't mean much when other Nodes are concerned, because their system clocks (or ours) might have drifted seconds or minutes apart from each other. On the other hand, there's probably a way evil Nodes could use a sequence of timestamps from a single source to deduce information they shouldn't know.
Alternative, credited to @czarte : Instead of inventing new CORES types, let's just use ICMP. Have the originating Node create an ICMP Echo request (opcode 8) and send it to an exit Node just as if it were an HTTP request. The exit Node forwards it on to a server somewhere, the server responds with an ICMP Echo Reply (opcode 0), and the exit Node calculates the server's latency and includes it in the response so that the originating Node can subtract it from the route's latency.
We'd have to introduce a new ICMP protocol--probably a new ProtocolPack and maybe some other machinery--and we'd have to build an implementation of the ping command into the exit Node (ProxyClient), but that might not be as difficult as introducing new Gossip types.
Possible blocker: We asked whether ICMP was sent over TCP or UDP, and found out that it's not a higher-level protocol than TCP or UDP, it's a sibling protocol. Like TCP and UDP, it's situated directly above IP. So, since ClientRequestPayload0v1 is completely focused on TCP traffic, sending ICMP through it would be such a huge special case from one end to the other that it might be more of a mess than just introducing new CORES types.
On the other hand, incorporating ICMP into the Node with an additional ICMP_Packet_0v1 CORES type would give us a good knowledge of what it would be like to incorporate UDP traffic into the Node. UDP would just be a UDP_Datagram_0v1 CORES type.