On Sat, 2 Sep 2000, Maarten ter Huurne wrote:
> > > How can a node (single computer in the network) determine whether its
> > > neighbours use JUMP or not? Especially, how can it do so without causing
> > > problems with other protocols?
> >
> > It can't. It is impossible to determine.
>
> I don't think it's possible to use JUMP and an incompatible protocol on the
> same network. So why not demand that every node in the network uses JUMP?
I put a note about it in the file. Because JUMP does not need a closed
ring, all that is needed to demand the whole network to be JUMP. But the
endpoints must be recognisable as non-JUMP.
> > Of course if too many bogus
> > packets are received, the driver may conclude that the connection is not
> > JUMP. A special header could be designed for non-JUMP protocols for when
> > they receive a JUMP packet, but they may choose not to use it.
>
> Even that is impossible. If the other protocol uses a different algorithm for
> sending packets, a node using JUMP wouldn't even be able to receive it's
> packets.
In which case the JUMP side will reject that side of the connection. The
other side will probably need a ring network, in which case it will hang,
or something.
> > > Also, it should be made explicit whether the link with the previous
> > > or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs,
> > > next.dat0, next.dat1 and prev.ack are outputs.
> >
> > True, this should be explicit. But not next and prev, because the network
> > is bidirectional. sender.A, sender.B and receiver.C should do, I think.
>
> The prefixes "prev" and "next" can be used on a bidirectional network. If the
> nodes are numbered, node N knows neighbour N-1 as "prev" and neighbour N+1 as
> "next". Especially when using a bidirectional network, "sender" and
> "receiver" is less clear, because either neighbour can fulfill both roles.
True. I shall soon change it.
> > With packets I mean packets that are sent in one go, without executing
> > other code while waiting for acknowledge signals or something. If you do
> > that, you can make use of a timed protocol.
>
> So you mean that sending or receiving a packet is an atomic action?
Yes.
> > Actually it is the being timed
> > that makes it possible to be bidirectional. A non-timed protocol must have
> > at least two lines (data and acknowledge) on the sender side. For joynet,
> > that means it must be one-directional.
>
> That's true. But does it really matter? A unidirectional network seems a lot
> simpler to me.
It is simpler to code, but slower and harder to get (you really NEED 2
cables for two computers).
> > The being timed also means you have to wait for the receiver to be ready.
>
> Synchronous transfer.
Indeed.
> > > In modem terminology, isn't SR called RTS (Request To Send)?
> >
> > Yes, I think so. I'm not really familiar with those things.
>
> If they are the same, it's better to use the existing term: RTS.
I already changed it in the file.
> > > Why are packets split up into 32 byte chunks? Usually, packets are the
> > > "atoms" of network communication.
> >
> > Packets can be really big (16kB e.g.).
>
> Why?
See below. I agree with you to chop them , by the way.
> It is common practice that a higher level protocol chops large data into
> small chunks. There is no need to send packets as large as 16K. And there is
> a reason not to do it: a 16K packet needs a buffer space of 16K and memory
> isn't abundant on MSX.
That is why I took 16kB as absolute maximum. A handshake should be able to
make it less. But it will be changed anyway.
> > I want to have a check every now
> > and then, to prevent the whole packet having to be resent and to have more
> > secure transmission. This protocol is (without the CRC's) much less
> > reliable than the unidirectional one.
>
> It would be much easier to stick to small packets. If packet sizes vary a lot
> (from a couple of bytes to 16K or larger), you have to pick a CRC that is
> good enough for the largest packets. If packets are small, you can use a
> smaller CRC, if you want to send a lot of data, you simply send a lot of
> packets.
True, but I thought it would be much slower.
> > I guess you thought the packets were smaller. We have to watch out for too
> > much packets. every packet, the sender has to wait for the receiver to be
> > ready. This means that the time wasted waiting is proportional to the
> > number of packets transmitted, no matter how large they are.
>
> You could make a flag in the header indicating that another packet will
> immediately follow the current one. The receiver will then return to "ready
> mode" as soon as it can.
That is a good idea :)
> > > Timing has some serious disadvantages:
> > > - it depends on how strong the joystick port drives the signals
> > > (probably not equal for all MSX types)
> > > - it depends on cable length
> > > (actually capacity, but length is probably the most important factor)
> >
> > This is true. There is a way to get around this however. It should be
> > used. I did not talk about it yet, since I forgot about it. It works as
> > follows:
> > The time between the setting of the signal and its reception is
> > non-zero. let's call it T. T must be measured and used in the
> > transmission.
>
> One problem is that T is not constant. It varies with temperature for one
> thing. And it may be other factors. You can solve those problems by adding
> some margin to T, although it will cost some performance.
That is the negative point of it, indeed. But I still think performance
decreases much more by using a unidirectional network, especially when the
network is large. Since there usually is a two-way communication, in a
unidirectional network the whole ring always needs to be folowed. In a
bidirectional network, the shortest path can be taken.
> Another problem is the granularity of the waiting loops. If you want to avoid
> self-modifying code, the fastest waiting loop is DJNZ, which takes 9 cycles
> for the last loop and 14 cycles for the other loops. So if you want to wait
> 10 cycles, you'll have to round to 23.
Timing must indeed be thought of. There is no need to round. Loops that
are the same every time can easily be coded.
> But on second thought, the propagation time may be neglectable compared to
> the time required for sending and receiving bits. The real problem is
> probably to synchronise those two well.
Indeed. A problem, but solvable.
> > > - it means the interrupt must be disabled when doing JUMP transfers
> >
> > Correct. I don't see this as a big problem.
>
> It's not a problem for small packets. It is a problem for bit packets.
> Packets of 16K could take a second or more to transfer. Leaving interrupts
> disabled that long will disrupt music and annoy a user who's typing.
Indeed. Therefore I am grateful for your suggestion on how to send big
chunks of data.
> There is another problem in the time before a transfer is started. The sender
> must wait for the receiver to be ready. If it waits while interrupts are
> disabled, interrupts can be disabled for quite a while (maximum: timeout
> value). If it waits while interrupts are enabled, the waiting can be
> interrupted and the receiver must wait for the sender, resulting in a more
> complex protocol.
Interrupts must be disabled during waiting and the timeout value must be
smaller than 1/60th of a second.
> > > - it is hard to program on PCs
> > > (file serving, internet connection, MSX emulators)
> >
> > Hard is my middle name (and I don't even have a last name :) ). Seriously,
> > the being hard to implement does not bother me.
>
> It should bother you!
> A protocol that's hard to implement will lead to more implementation bugs,
> more complex code, more time before it's fully implemented and less chance
> that someone will implement it for other systems.
Hmm, you have a point there.
> And after solving all the complex issues, there will be compromises on
> performance, so the main advantage of a timed protocol may diminish.
You may be right. Are you suggesting to rewrite the document to a
unidirectional format? I want to know what other users think of this
before I do it. (so please react if you care about what it will be)
> > > While the receiver reads the bits, the sender is doing nothing. But they
> > > should remain in sync, so either the receive time must be substracted
> > > from t2 or the sender must wait an amount of time equal to the receive
> > > time.
> >
> > In the scheme I assumed all read/write operations to take 0 time. Of
> > course they don't really. The one acting should know the time used for the
> > operation and act as if it was waiting.
>
> "Know the time used for the operation" is not as simple as it sounds. It's
> different for Z80 at 3.5MHz/6MHz/7Mhz/8MhZ, R800, Z380 and non-MSX machines.
> And on machines with a cache it's impossible to calculate exactly, you can
> give only minimum and maximum times, but that's not good enough. Even the
> simple fact that the R800 doesn't send CAS (or was it RAS?) when it isn't
> needed adds a lot of complexity to the calculation (it matters how many
> 512-byte boundaries are crossed by the code).
Hmmmmm, that makes things awfully complicated, indeed.
> > > Are collisions possible?
> >
> > Yes.
> >
> > > If there can be no collisions, collision detection is not necessary.
> >
> > True. But if there can be no collisions, the protocol is unidirectional.
> > since the cable does not permit full-duplex mode.
>
> A collision means that there are two signals on the same wire at the same
> time. As far as I know, that will never happen with JoyNet. What can happen,
> is that two neighbours want to send to each other at the same time, but
> that's no collision.
Hmm, ok. It's a question of definition. I defined a collision as two
packets going over the same wire while it can handle only one. The cable
is an abstract line that can carry a stream of data, in this case 3 wires
of copper.
> > > Why is the packet sent in 32-byte chunks instead of 16-byte or 256-byte?
> >
> > I think there should be a standard for it. It doesn't really mean what the
> > standard is. It is a good idea to make it a changable value, like the time
> > unit. But there must be a standard for the handshake, so I just chose one.
> > There is no deeper meaning of it, except that I thought those values would
> > be implementable on a msx.
>
> OK, please add that information to the specification.
I shall do that soon.
> Maybe we should make JUMP packets large enough to contain IP packets? That
> would make IP-over-JUMP a lot easier. Actually, maybe JUMP should only
> describe the network layer and we can send plain IP packets over that.
That is a good idea. But I don't know enough about IP packets to design
it.
> > > Maybe you should demand that the new document contains the serial
> > > number of the previous document the new one was based on?
> >
> > If someone changes an old document and feels the need to say it is not
> > best version in her opinion, I should think that she writes that in the
> > document. But I don't think there is a need to demand it.
>
> I agree with Manuel here. It's not about a "best" version, it is simply
> useful to know the "evolution tree" of a document.
Hmm, ok. So the parent must be named in every document. By the way I don't
keep my old versions of it and I don't expect others to. There is no
archive of them, which makes it a bit useless, since you cannot see the
tree anyway.
> I really urge you to reconsider having a timed protocol. It may sound like a
> simple idea with a few complications that can be solved with some good
> thinking. But I think that in fact it's impossible to make a clean and
> elegant implementation of a timed protocol, given the fact that it must run
> on many different machines.
>
> For example, running JUMP inside an MSX emulator would be almost impossible,
> unless you would implement JUMP in the emulator itself. A protocol without
> timing could only require that the emulator connects the emulates joystick
> port to the PC parallel port, it wouldn't require any knowledge of the JUMP
> protocol in the emulator.
True. I think you are right and I want to rewrite it as non-timed, but I
want the MSX community to decide on this. It is not my personal protocol,
it is a standard. So if now I get many mails asking me to make it timed, I
shall do that. But I don't think I will...
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44> x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16 >i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
