[HECnet] What use are *you* making of HECnet?

[Johnny Billquist]

Jason Stevens wrote:
On Thu, Feb 26, 2009 at 8:19 AM, Johnny Billquist <bqt at softjar.se> wrote:
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.
There is libpcap for windows, you can do it... although I was going to
remove the physical access, and just have it forward the packets...   A
bridge in the sky as it were.

Well, normally libpcap is used to recieve packets, so it don't neccesarily help with sending them.
Second, sending packets is one thing, sending packets with a "fake" source MAC address is yet another thing (as a short note, the DEUNA and DELUA ethernet controllers for the Unibus can never do this. They set the source MAC address from the controller, no matter what you place in the packet you want to send).

But please report if you have success with this.

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?

Well if you were trying to send the whole 1500 bytes of data + headers
in the UDP packet won't it cut stuff off?   I know TCP will do the auto
fragment & reassemble, so you won't notice it... I haven't stressed
the thing out yet, just some simple ICMP stuff at the moment.. I
should add, I've added code to send thru ARP/RARP & IP since I don't
have any idea on configureing networking on VMS..

No. Two different things.
TCP intentionally sends short enough packets that they don't get fragmented. TCP then keeps track of everything to actually recreate a stream of bytes at the other end. IP will fragment packets if needed, no matter if you use UDP, TCP or any other protocol that is transported on top of IP.

That is, unless the datagram have the DF flag set (don't fragment), or the IP implementation haven't implemented fragmentation. They should, but there are always the odd implementation that might not do it.

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.

Yeah that's what I was trying to avoid.... I mean it's not that hard
to sequence things, and have it note fragment numbers, and of course
being aware of the sequence and reassembly.... But then at that point,
it'd be easier to just use TCP.. As for the compression I was thinking
more so of loading a HECnet enabled version of SIMH on an iPhone... I
know not the most 'usefull' but I think it'd be cool to have a pocket
VAX on the network...

But compression of the network traffic is still not a gain, even on an iPhone (I think).
There are several reasons I prefer using UDP over TCP for HECnet. Not the least that it's okay to actually drop packets, or get them out of order. Using UDP also adds minimal overhead. And it's naturally packet oriented. If I were to use TCP, I'd have to reassemble the stream into packets. That means I also need to transfer packet size before each packet, and a lot of "boring" extra work.

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.
Thanks for the input, yeah I need to play more with it, I do like the
realative simplicity of it... If anything now that I think I got SIMH
tied into it ok, I wanted to add Qemu support, and whatever emulators
I can also find to build up some emulated network.. And again tying
back to a stubbed windows server that I have on the internet.   In the
age of multi Ghz cpu's I don't think libz would be that much
overhead..

Lot larger memory footprint, more cpu usage, maybe larger packets. :-)
I still hate watching resources wasted, even if todays machines are fast. :-)

	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