On Fri, 18 Aug 2000, Maarten ter Huurne wrote:
> On Fri, 18 Aug 2000, you wrote:
>
> > 3. When JUMP should be used
>
> The term "JUMP" is not introduced...
> JUMP = Joynet Univeral Message Protocol?
Hmm did I forget that? sorry. It should be Joynet Unified Machine
Protocol. I used this term to emphasize the fact that it is not a MSX
protocol, but a protocol for the cable. Any computer that can set the
signals on the cable can make use of the protocol.
> > 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. 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.
> > 4. Why JUMP should be used
> >
> > The reason to have a standard protocol is simple. many coders can make many
> > network programs and they all want to communicate with each other. If there
> > is no standard protocol, every computer would need drivers for all
> > protocols.
>
> In the case where there is only 1 application running on the network, JUMP is
> not necessary. However, if you want to create a Joynet ring that really acts
> like a network, a protocol like JUMP is necessary. So JUMP is good for TCP/IP
> over Joynet, file serving and such.
Exactly. Thank you for expaining.
> > In the rest of this document, I shall address the lines by the letters A, B
> > and C. A and B are the lines comping from the buttons. C is the line going
> > to steer left. A and B are outgoing lines and C is an incoming line on one
> > side. With the computer on the other side, A and B are incoming and C is
> > outgoing.
>
> 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.
> 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.
> > 6.1. General overview
> >
> > 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. 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.
The being timed also means you have to wait for the receiver to be ready.
So I was actually talking about the results of a timed protocol (which
must nessecarily work in packets).
> By the way, are there low-level network protocols that do not send data in
> packets? I can't remember seeing one.
I used one in Boulderdash III. You can check out the source on my homepage
if you like: www.fmf.nl/~shevek ->msx
> > 6.2. Sending a packet
> >
> > 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.
> > Sender sends header
> > Receiver sends CRC1 and packet size back for confirmation
> > Sender sends confirmation
> > While (packetlength >= 32) {
> > Sender sends 32 bytes of the packet
> > Receiver sends CRC0
> > Sender sends confirmation
> > first 32 bytes are cut off packet
> > }
> > Sender sends remaining bytes of packet
> > Receiver sends CRC0
> > Sender sends confirmation
> > Receiver sends CRC1
> > Sender sends confirmation
>
> 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.). 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.
> > 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?
> 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. So if it is
possible, the number of packets should be reduced. This does mean packets
will be larger.
> > Sending of
> > bytes is done by sending the bits on a timed basis, as is shown.
>
> 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. When the acknowledge signal arrives, the sender must know
that T has been elapsed already and that it will elapse again before the
signal it will send arrives. T itself may not be the same for the
computers on eigther side of the link. It cannot be measured without
another way of synchronising the computers. Luckily, only T1+T2 needs to
be known and that can be measured. I shall think about this and include it
in the handshake of the protocol (It didn't need a handshake, now it
does).
> - it means the interrupt must be disabled when doing JUMP transfers
Correct. I don't see this as a big problem.
> - 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. I shall write the driver
for linux, if anyone feels the need of writing it for an other OS (ms-xxx,
c64, atari, amiga, etc) she is very welcome.
> > Both wait a time t1
> > Receiver reads bit [i;i+1|i] from [AB|C]
> > Both wait a time t2
>
> 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.
> > 6.4 Control signals and collision detection
>
> 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.
> > Please let me know what you think of it. If anything is not clear or you
> > want it different, let me know.
>
> What is most unclear to me, is why the design decisions are made. The timing
> values, why are they chosen as they are? 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.
> One thing you haven't addressed, is how the protocol handles broken network
> links, like a disconnected cable or a neighbour that is powered down or
> doesn't run a JUMP implementation. You don't necessarily have to handle those
> situations, but at least say something like "in the case of no response, the
> protocol is allowed to hang". It's better to be explicit.
I mentioned the timeout t4 (probably I mentioned it later in the document.
Sorry ;) ) When the sender waits for a CTS from the receiver, a timeout
should occur after a specified time. I don't remember how much it was. If
this happens, a total reset of the protocol should be done. The handshake
should start over. Because there is a maximum timeout time, one computer
can force the other to a timeout, thus restarting the handshake. If the
handshake fails, the network is down. The protocol is not allowed to hang.
> Another thing that is missing, is how different nodes are addressed. Assume
> that I want to send data from node 2 to node 5, how do I specify those
> addresses? How do nodes get their addresses in the first place? Are
> broadcasts possible?
This is part of the header. As I mentioned in an other mail, I forgot to
describe it. It doesn't really matter, since I think what is here now
should be enough for some discussion. I shall place the complete document
on my homepage:www.cpedu.rug.nl/shevek/JUMP.txt (mind the capitals). The
header part is not finished. Most of all, I would like remarks about
impossibilities in the protocol. If there are any, that is. I tried not to
have any of course ;)
As a reaction to Manuel:
> Anyway, I am not a good enough coder to make real comment here, so
> here is my lousy comment:
All comments are welcome :)
> > way, higher serial numbers will always be later versions of the
> > document. This does not mean it is more up to date. An author can
> > change an old document and add a new serial number. Anyway, let's get
> > to the point.
> So if an author changes an old document and adds a new serial number,
> your whole system is useless.
Not at all. The system is not meant to find the newest version easily
(although it is what will also happen in practice), but only to make the
documents distinguishable without the need of diff. And most of all, it
makes the documents referencable.
> 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.
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/
****
