Re: OT: Incoming/Outgoing route of IP subnet
Alexander Steinert <stony8@gmx.de> writes:
>
> 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
> experiment.
It depends on how the device is used. If it's making many
simultaneous connections to hosts beyond a gateway, most of the MAC
addresses are duplicates because they're all equal to the MAC address
of the gateway. It would be better to find a few free bits in each
transmission control block that can index an array of MAC addresses.
In general, I think it's better design to decouple the TCBs from the
ARP table (even if you only store MAC addresses in the table indexed
by the TCBs) because it gives you the freedom to vary the size of the
ARP table. You can always drop cached ARP entries and take a
performance hit; you can't drop TCBs without dropping connections.
In any case, I don't think you save anything RAM-wise by not properly
supporting asymmetric paths---whether the path is symmetric or
assymetric, you need to map each remote IP address to its destination
MAC. You might save some ROM by not implementing complete ARP
request/response behaviour, but not RAM.
--
Kevin <buhr@telus.net>
Reply to: