At 07:00 PM 10/12/98 +0000, you wrote:
>I think you are both mistaken here. In synchronous communications,
>the exact point in time at which the data signal(s) is sampled, is
>determined by an 'extra' signal, an other signal, and with that, the
>data stream is SYNCHRONISED with that other signal.
What you call an 'extra' signal, is just as much part of the signal as the
data signals are. Dependant on the encoding, it may not even be possible to
say "these bits are data and these bits are timing".
Take for example the encoding I proposed on this list a while ago:
There are 2 signal bits: D0 and D1.
Flipping of D0 means "a 0 is transmitted".
Flipping of D1 means "a 1 is transmitted".
Since the timing information is part of the communicated message, the
sender and receiver need not be synchronized.
>If such an other signal is not used, or not present, the data stream
>can NOT be SYNCHRONISED with that other signal, and thus becomes an
>ASYNCHRONE communication method. In this case, it is usallly a fixed
>timing scheme that determines when bits are to be sampled. Such a
>fixed timing scheme is usually referred to/derived from/related to as
>"baudrate". This is the common way used for RS-232 communications,
>and the same goes for MIDI-connections (also Asynchronous).
Because the signal itself doesn't include any timing information, you do
need external synchronization.
I'm not sure the reasoning I used above is the one used for the
name-giving. But I have had a couple of courses at the university about
asynchronous computing and communication, so I know what's asynchronous and
what isn't.
>Besides: if JoyNet only standardises the cable, than that leaves the
>programmer free to choose for a synchronous or an asynchronous
>communication method.
It does.
I just strongly recommend an delay-insensitive asynchronous communication
protocol, because that will give far less trouble. For example, it is
insensitive to cable lengths and it will run at any clock speed.
>If the number of connection lines in the cable
>is such, that no extra lines besides the data lines are available,
>then that would automaticly force asynchronous communication to be
>used. If not, both methods could be used.
There are two bits available for sending, which is enough.
>-For networkgames, SPEED is crucial, and error-checking not that
>important, or not at all
There are two speed factors that are important:
1. the delay before actual data is sent
2. the time it takes to send the data
Point 1 is caused by the fact that the processors of both the sender and
the receiver need to actively participate in the transfer handshaking. The
sender has to wait until the receiver is ready to start the transfer.
If the amount data you have to send is small, point 1 is far more important
for the performance of your game than point 2 is.
Transmission errors in games are *not* funny random effects. They can ruin
the game in progress.
>-For data-transfer, speed is not THAT important, and error-checking
>might greatly improve reliability.
I too think reliability is important. But you suggested 32 bit CRC without
any proper argument why what error detection would be the right one.
Besides, error detection depends on message size as well. One 32 bit CRC
per kilobyte offers far better error detection that one 32 bit CRC per
megabyte.
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
