Jason Stevens wrote:
Right now testing, although I'm making a 'stub' version to run under
windows so I can setup a bridge on a windows hosting box I have...
Hmm. I suspect that might turn out to be very hard, if not impossible...
One of the serious problems is that you need to be able to send out packets with faked
source MAC addresses. And all tools I've ever worked with in Windows which need to use
some other MAC address have been tricky to say the least, not to mention that you need to
reconfigure, and for some, also reboot the machine to use another MAC address. Transparent
ethernet access from Windows seems to be difficult.
I noticed from the source there is no way to handle packets of 1500
bytes, as it would invariably require fragmentation... is
LAT/MOP/DecNET all smaller then 1500 bytes?
I'm not sure how you mean. The code bridge ethernet. Ethernet packets are (normally) a
maximum of 1518 bytes. 1500 bytes of data, 6 bytes source and destination MAC, two bytes
with protocol number, and four bytes of CRC.
Is there somewhere where you have identified that the bridge program don't handle 1500
bytes of data?
I'm not really interested in jumbo ethernet frames. No DEC equipment relevant here
supports it anyway, so there is no need.
As for fragmentation... Now I assume you are talking about the encapsulation of ethernet
packets in UDP packets. Those will be a bit larger still, and will almost certainly be
fragmented when sent over the internet, yes. I don't see a problem with that. Do you?
I've only used decnet in the 'wild' once, but we moved from the VAX to
PC's... but then our VAX was weird as it ran Novell Netware..... I
wish I had saved the tapes, as netware for the vax has to be super
ultra rare...
Yeah. That would have been fun to have kept around.
Anyways I was thinking of adding compression support (zlib style)... I
should test it some more as I figure if the packet compresses somewhat
it'll be under the 1500 snaplen for ethernet....
Feel free. I'm not sure there is a point of doing so, but anyway.
If you want to avoid fragmentation of packets, you need to find out what the minimum MTU
are along the whole path between two nodes. And your packet then needs to fit both the
data to carry as well as the UDP and IP header within that packet size. The minimum size
that is guaranteed by IP to not be fragmented is 576 bytes. For UDP that means a size of
the data part of just 548 bytes.
And that means you need to do fragmentation yourself, since you'll never be able to
squeeze 1500 byte packets into 548 bytes with any kind of certainty. And if you start
doing the fragmentation yourself, you will in fact add to the overhead, since then
you'll create a separate packet for each fragment, all with their IP *and* UDP
headers. And you'll need to do fragment reassembly, and what will you do if some
fragment is missing? Do retransmissions? Now we're getting into a very complex
protocol with acknowledgements and whatever. And don't forget the cpu overhead of
doing the compression/decompression of each packet. And if you start to have fragments,
acknowledgements and so on, you'll have to add information to each packet to handle
all this information, which means extra overhead there as well. In the end, you should not
be surprised if your packets end up being larger than the current ones.
And in the "normal" case, each packet is still just generating a single,
unfragmented IP packet anyway.
Like I said. Feel free to play with it, and see what you can do. But personally I
don't think it's a good idea. You add complexity, processing overhead, protocol
overhead, and possibly a whole new level of communication overhead, to probably no gain at
any corner, but at a cost of having a protocol that makes it harder to troubleshoot. :-)
Ok enough rambling for now.
I hope my ramblings don't scare you off, or turns you off from experimenting. Having
fun and experimenting is after all what HECnet is all about.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic
trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" -
B. Idol