Re: MiDI driver for MiNT-net?

[hyc@locus.com (Howard Chu)]

  Howard Chu wrote:
  > Yes, there's a problem here - using MIDI-thru means that every packet alway
 s
  > goes to every node, even if it's not a broadcast packet. In this case, you 
 need
  > to introduce a MAC-layer protocol if you want to be able to distinguish
  > broadcast packets from regular packets. It may not be worth the effort or
  > added processing overhead.

  I must admit I was thinking there would have to be a MAC/link layer protocol
  (midiring.xif?).  I don't think you can just drop IP onto the wire.  For
  example, you could end up reducing the IP so much that a packet originating
  on the ring wouldn't traverse much of the real 'Net; and reducing the IP TTL
  by one per midi station wouldn't stop the packet (maybe) traversing the ring
  several times.

This assumes that you pass the input packet all the way into the IP layer,
thus decrementing the packet's TTL. I was talking about only checking the
destination IP address, and immediately passing the packet on if it didn't
match. But, I suppose this is a problematic approach, and a MAC layer is
best. (My original notion doesn't allow for routing, for one...)

  Exactly, if MIDI-thru is used to copy packets, I can't see any way to ever
  remove them from the ring!  At least with ethernet, the propagation stops at
  the ends of segments.  I think the way to do the propagation is to do the
  manual copy.  It wouldn't have thought the processing overhead would be
  much more than (say) a PPP driver (isn't that basically a point-to-point
  link level driver?) and we are not talking about a high speed net here
  either!  Can you treat the ring as a full duplex net?  I would have thought
  that there is only a limited amount of bandwidth available and you wouldn't
  want to squander any of it (c.f. CSMA-CD ethernet).

  If you have a MAC layer protocol, you only have to look at the first few
  bytes before deciding what to do with the packet (discard, pass on, pass up
  to IP level).  And you can pass other types (non-IP) round too ...

Yep, why limit ourselves (the way SLIP did) when we can be protocol-agile
(like PPP). Ok, that was an easy argument.

  Hmm, passing the IP in MIDI SYSEX sounds a kinda neat solution!  Can you send
  broadcasts around?  You would need them for the ARP and address finding
  packets.  The M(IDI)ARP table could be constructed just like an ether one.

Oops. Ok, so now we're reminded that SysEx is not channelized, which means
it pretty much *is* a broadcast, as long as things are set up correctly.

  > If you're passing a token, you don't need to use fixed-size packets. But,
  > you do have to wait for the token to completely traverse the ring before yo
 u
  > can send again, and that could cause high latency.
  > 
  > Actually, assuming all traffic is local to the ring (nothing routed in from
  > an external net) I think you can guarantee that the ring won't overflow,
  > using variable sized packets. I guess this also applies to TCP only, in whi
 ch
  > case every transmitted packet will wait for an ACK...

  Well, I assumed the case where one (or more) of the machines on the ring
  might also be a gateway to somewhere else.  Even if there is no gateway,
  wouldn't it be possible for two (or more) machines to try and add packets
  to the ring in the same circuit, thus overflowing the ring?  How does
  SYSEX work?  Does it use 16 independent frequencies on the ring, so that
  multiple transmissions co-exist?  Where can I read the spec?

It would be possible for a datagram user (UDP, IP, ICMP) to swamp the ring
by continually sending data without waiting for ACKs. But for TCP, every
transmitted packet must eventually be ACK'd, or else transmitting stops.
If any single machine in the ring gets too bogged down and starts dropping
packets, the TCP stream will automatically be flow-controlled by virtue of
this fact. Again, this assumes that each machine on the ring is manually
copying from input to output. 

The problem with this approach is that every machine on the ring needs to
be up at the same time, and stay up. If any one machine crashes, the ring is
broken. Also the ring is as only as fast as the slowest node. We can use MIDI
Thru instead, on every machine except one, which has the privilege of being
"ring master" and making sure no packets travel around too many times. In this
case, the ring's reliability is better, and the speed is limited by the speed
of the master machine. It really becomes a broadcast network, which I'm not
sure is a good thing. 31.25kbps is not a lot of bandwidth to be sharing with
a lot of machines...