[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MiDI driver for MiNT-net?



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

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?

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.

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

J

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

-- 
"IP over everything"