On Fri, 01 Sep 2000, you wrote:
> > > If a coder wants to make a program (probably a game) that should run on
> > > multiple computers, she may use any protocol she desires. If she has a
> > > way of knowing what the other side of the connection does, for example
> > > because it also runs her software, she does not need to follow JUMP. It
> > > is advisable however, to check if the computer is at that time in a
> > > JUMP network, because the network would be suffering from the (for
> > > JUMP) bogus packets that seem to keep coming in.
> >
> > 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?
> 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.
> > What about naming them "dat0", "dat1" and "ack"? Those names are easier
> > to remember.
>
> I don't think so. A and B are very logical, because on the msx they are
> connected to joystick button A and B. I chose C as `the other line',
> because I didn't feel the need for a different name. `ack' suggests that
> it is only used for the `acknowledge' pulse, which is not true in this
> protocol.
OK.
> > 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.
> > > Jump is a protocol that works in packets. There are positive and
> > > negative sides to that. The most important negative point is that the
> > > sending computer has to wait for the receiving computer to be ready.
> > > The most important positive point is that the data flow can be
> > > bidirectional.
> >
> > I don't understand: why are these properties consequences of using
> > packets?
>
> 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?
> 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.
> The being timed also means you have to wait for the receiver to be ready.
Synchronous transfer.
> > > Before sending, a send request (SR) should be given. After that, the
> > > sending computer has to wait for a reaction (and check for collisions,
> > > see below). When the client has seen a send request, it sends a clear
> > > to send (CTS). After that, the transmission begins. It works as
> > > follows:
> >
> > 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.
> > 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?
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.
> 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.
> > > This is the complete transmission of a packet. CRC0 is a 8 bit CRC on
> > > the data that has just been received. CRC1 is a 32 bit CRC of all
> > > received bytes*3.
> >
> > I think we had this discussion before, but 32 bit CRC is overkill for
> > small chunks of data.
>
> I missed that discussion. Did you consider 16kB small, or did you think
> packets were much smaller?
I assumed packets are much smaller.
> > For example, MSX floppy uses 16 bit CRC for sectors (512
> > bytes long).
>
> 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.
> > 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.
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.
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.
> > - 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.
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.
> > - 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.
And after solving all the complex issues, there will be compromises on
performance, so the main advantage of a timed protocol may diminish.
> > 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).
> > 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.
> > 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.
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.
> > 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.
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.
Bye,
Maarten
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
