Re: MiDI driver for MiNT-net?

["J.D.Coleman" <J.D.Coleman@newcastle.ac.uk>]

Howard Chu wrote:
> Yes, there's a problem here - using MIDI-thru means that every packet always
> 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.


> I have written both IBM Token Ring and FDDI drivers for SysV DLPI. Actually
> using the MIDI-thru would be more similar to Ethernet than to Token Ring. I
> don't think it would be practical from a hardware standpoint, because if the
> Thru line is connected in a complete loop, there is no way to remove a packet
> after it has traversed the entire ring.
> 
> Instead, you have to manually byte copy from MIDI-IN to MIDI-OUT. In this
> situation, as long as the MIDI port is fully buffered, you don't need to
> operate in Token-passing mode, you can just treat it as a full-duplex net.
> 
> Without use of a MAC-layer address, each station has to fully decode the
> source & destination IP address before deciding whether or not to copy the
> packet from MIDI-IN to OUT. (For non-broadcast packets you only need to check
> the dest.)

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 ...


> Yah, actually you could hide IP-packets in MIDI SYSEX packets, and just use
> channel numbers as the MAC-layer addresses. This way you could possibly even
> keep your computers coexisting with your MIDI instruments.
> 
> You would also need some kind of an ARP protocol. That can be interesting to
> implement. Or, I suppose since 16 nodes isn't too bad to deal with, you
> could just build ARP-table equivalents by hand...

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.


> 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 you
> 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 which
> 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?

J

--