On Fri, 18 Aug 2000, you wrote:
> 3. When JUMP should be used
The term "JUMP" is not introduced...
JUMP = Joynet Univeral Message 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?
> 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.
> 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. 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.
> 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?
By the way, are there low-level network protocols that do not send data in
packets? I can't remember seeing one.
> 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)?
> 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.
> 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. For example, MSX floppy uses 16 bit CRC for sectors (512
bytes long).
> 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)
- it means the interrupt must be disabled when doing JUMP transfers
- it is hard to program on PCs
(file serving, internet connection, MSX emulators)
> 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.
> 6.4 Control signals and collision detection
Are collisions possible? If there can be no collisions, collision detection
is not necessary.
> 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?
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.
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?
Bye,
Maarten
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
