To: papval@otenet.gr
From: dlanor@oden.se (Ronald Andersson)
Message-ID: <3829e2d6202f1b7@oden.se>
Subject: Re: Bug in your serial patch
References: <381f5c521672b70@oden.se> <3822eb4c26053e1@mail.otenet.gr>
 <3823ad3e6002ec2@oden.se> <3825892a3e28680@mail.otenet.gr>
In-Reply-To: <3825892a3e28680@mail.otenet.gr>
X-Mailer: Okami Version 2.1B-9
Date: Wed, 10 Nov 1999 21:42:16 +0100 (MET)
Lines: 119

Hi Vassili,

These have been pretty busy days for me, which has delayed some replies,
not just to you but to some other as well.  Still I'll get around to
them all eventually.  As some time has passed since the original mail
I will use more careful 'snip' rules than usual.


on Sat 06-11-1999 15:43 Vassilis Papathanassiou wrote:
>on Sat 06-11-1999 00:13 Ronald Andersson wrote:
>
----- snip ----- re: the 'my_receive' code that garbled incoming data
>>
>Yep, that is true. Garbling could happen if someone was sending eg XModem
>data to a port that STinG 'listens' for SLIP/PPP traffic.

You misunderstood what I said earlier. I actually observed TCP/IP traffic
being garbled, so that CAB displayed garbage pictures on web pages etc.
Yet when Serial 1.15 was installed the same pages displayed perfectly.

This means that the garbling occurred *after* physical reception by the
serial driver, and that it occurred in such a way as to bypass checksum
tests.  Unfortunately that can easily happen, as TCP/IP checksums use a
very primitive method.  (as compared to CRC for exanmple).


>>What your code did there was to remove a 'leading' end mark, but with
>>no consideration that it might actually be a 'trailing' end mark for
>>older data, already held in the buffer as the call started.
>>
>No, my code was not trying to remove the end mark, it just moved the
>buffer pointer past it and started searching for the next mark. If
>a second mark was found or not found, it went processing the datagram
>if the pointer was greater than the buffer. Your fault was to think
>that the inner while loop was 'redundant' which it wasn't, since it
>was taking care that probably we have more than one datagram in the
>buffer (possibly an unfinished from the previous pass and a new).

I see what you mean here, but that is not quite what the code achieved,
as the 'garbling' I describe further above could be triggered both with
the SERIAL.STX that you sent me, and with my early modifications of it.
(Just by waving the mouse about, or any other CPU-time consuming work.)
Later versions (from 1.18 and on) are immune to that effect.


>> My new
>>code (currently 1.19) does eliminate 'leading' marks too, as this is
>>necessary, but it does so in a different way.
>>
>No, it does the same

Not quite.  But it is difficult to spot the difference, I know that,
as that is why I too missed it in my first attempts to fix it.


>(and fortunately you came back to > 1 and not > 3
>and since you did it, there is no reason to explain why)

I like to keep the reasons straight. Here the reason is simply that we
also deal with PPP packets, and I can make no valid assumptions about
their sizes at all, except that they need more than the 'mark' byte.


>but it does
>it without the inner while loop and thus it's easier to read it :-)
>It works fine too (v 1.19) so I have no objections anymore.

Good.  These parts are naturally unchanged in version 1.20 as well.


>Note that I wasn't able to find any problems with v 1.16 even after
>loading a hell of a lot of images to CAB (some of them very big in
>size).

The problem was very timing dependent.  I could usually trigger it
by intense mouse movement, but not on every transfer, and not at all
for very short files.


>Needless to say that all other LAN traffic was without
>problems also. This wasn't true during my tests before I sent you
>v 1.16, so I knew that even the slightest bug in handling the input
>buffer could result to at least a lot of dropped packets (driver or
>IP mostly).

Yes, this kind of code is very sensitive, and any error can have some
far-reaching consequences, as all other protocols depend on the basic
driver to transfer everything according to specs.


>>Actually this should simplify things a bit, as there is now again
>>only one version each of 'my_send' and 'my_receive'.
>>
>Yes, and this is really nice. The work you did with HSMODEM seems great
>so far, I hope it will make even the slowest systems to perform better
>(this is where I think we'll get the best results).

It should, but I'm afraid (judging by reports) that most users still have
too unoptimized configs to get the most out of the new modules.  It will
not help much, having fast serial transfer, if DEF_RTT set to 50 wastes
most of that speed on retransmissions...  :-(

I'll have to make a special point of explaining optimized configs in the
next version of the STinG HYP.  And of course, make the new DEFAULT.CFG
in the distribution archive more sensible to begin with.

I really want to gain control of the other components too (dialer & CPXs),
before making a new distribution archive, but perhaps I should not wait for
that.  After all, each new user that downloads the current one still ends up
with totally unoptimized setting that make life harder and STinG slower...

What do you think of a new distribution archive release at this point ?
(After adding some stuff to the docs too of course.)

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------
