68ba2f74a6
This is a major change to the previous design, and also a change with respect to the semantics in the ESOP 2016 paper. All the complexity of echo-cancellation is stripped out of the core dataspace semantics, and the relaying protocol is changed from one constructor, `at-meta`, to two, `inbound` and `outbound`. The relay connecting a dataspace to its container is now completely symmetric with the contained actors: it initially asserts interest in what it is to relay, just like any other actor would. Dataspaces no longer treat relaying specially. This commit has updated all (I think) of the non-graphical examples. The graphical code remains to be done in a following commit. |
||
|---|---|---|
| .. | ||
| Makefile | ||
| README.md | ||
| TODO.md | ||
| arp.rkt | ||
| checksum.rkt | ||
| configuration.rkt | ||
| demo-config.rkt | ||
| dump-bytes.rkt | ||
| ethernet.rkt | ||
| fetchurl.rkt | ||
| ip.rkt | ||
| main.rkt | ||
| on-claim.rkt | ||
| port-allocator.rkt | ||
| tcp.rkt | ||
| udp.rkt | ||
README.md
TCP/IP Stack
Linux Firewall Configuration
Imagine a setup where the machine you are running this code has IP 192.168.1.10. This code claims 192.168.1.222 for itself. Now, pinging 192.168.1.222 from some other machine, say 192.168.1.99, will cause the local kernel to receive the pings and then forward them on to 192.168.1.222, which because of the gratuitous ARP announcement, it knows to be on its own Ethernet MAC address. This causes the ping requests to repeat endlessly, each time with one lower TTL.
One approach to solving the problem is to prevent the kernel from forwarding packets addressed to 192.168.1.222. To do this,
sudo iptables -I FORWARD -d 192.168.1.222 -j DROP