Re: OT: Incoming/Outgoing route of IP subnet
> > I'm implementing an TCP/IP/ETH stack on a small device and wondered if I
> > can simplify the ARP part and spare RAM by the assumption sketched
> > above. One could remember the MAC src address of an incoming frame and
> > use it as the MAC dest address for answering frames. No ARP requests
> > would be necessary, only ARP answers.
> I don't think you'll save RAM this way, at least as far as the ARP
> table is concerned. Instead of having one ARP table entry for each
> machine on the local network including the gateway, you'll have an ARP
> table entry for every machine that talks to you from anywhere (most
> with MAC addresses pointing to the gateway).
OK, let's assume I have less than 400 bytes RAM for TCP/IP... and the
application. I cannot store more than a few TCP connections! A possible
ARP table would be very small also. So the question is if, for most
environments, one could spare the ARP table and store the destination MAC
address with the TCP connection data. On top of ETH there would be only
IP and on top of IP there would be only TCP. It's a kind of thought
> You can save yourself the trouble of generating most ARP requests by
> caching the source IP->MAC mapping of any ARP requests you receive.
> See the "Packet Reception" section of RFC 826 and the talk about
> bidirectional communication in the paragraph following the flow
Thanks for the hint.