Re: MiDI driver for MiNT-net?

[hyc@locus.com (Howard Chu)]

We did some MIDI tricks like this in KA9Q, 'way back in '87. I think I can
shed some light on this...

  Dancer wrote:
  > > Making "broadcasting over midi" work should be no problem with midi-thru.
  > > If I get it right, if you connect some ataris with midi and one sends
  > > something *all* connected machines will receive the data on the midi-wire
 ,
  > > right?

  > > If so broadcasting works automatically: if one machine sends a packet all
  > > others will receive it, but when matching the destionation IP addresses
  > > in the packet header all but the destination machine will trow away the
  > > packet.

  > Erm...There's a problem, I think. Each machine that recieves it will try
  > to route the packet according to their routing tables, IIUIC. That would
  > mean that a packet that arrives at a machine for which it is not intended
  > will go back out the 'default' route. That will mean that a copy of the
  > packet would bounce around the network until it's TTL expired. (Multiplied
  > by the number of 'incorrect' receivers, unless sequence numbers squash
  > them).

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.

  Presumably there has to be some further processing done here.  As far as I
  can see you would need a link level to -

  	register a machine on the ring with a unique address
  	monitor/add/discard packets on the ring
  	
  I don't think you should be reducing the IP TTL at each station on the ring
  - only the machine that sends it off the ring (c.f. a 'normal' router).

  The midi ring driver would need to do the link level stuff.  Does anyone know
  anything about token-ring or FDDI link level drivers?  How about midimaze and
  such?

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

  My thoughts -

  	- each machine on the ring has a an id (max 16?) and it passes
  on all packets that were not destined for it and also not originated by it
  (in case the indented receiver missed it - this stops packets circulating
  for ever).  Presumably, to use midi as a ring, you would need some sort of
  token circulation instead of the (much simpler) use as a point-to-point
  connection over two separate cables.

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

  	- to send a new packet onto the ring, you will need space on the
  ring to fit your packet.  You don't know if the preceding station is just
  about to send you data, so what do you do?  Two alternatives that I can
  think of -

  	1. Variable sized packets - queue the incoming data whilst you send
  and then transmit the queued data.  Can you overflow the ring like this?
  	2. Fixed sized packets - Wait for a token to come around and put your
  data in it.  This could be wasteful of space (therefore speed), but seems
  easier to implement.

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

  J

  PS.  Is there any interest in a version of Toswin with VT100 & VT52 emulation
 ?

Might be useful. Personally I've only been using Miniwin lately, and I've
already written a terminfo description for it that does everything I need.

  -- 
  "IP over everything"

Howard Chu				Principal Member of Technical Staff
hyc@locus.com				PLATINUM technology, Locus Laboratory