🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: demon.ip.developers
Article #1195

Re: SMTP implementation in KA9Q

#1195
From: Richard Clayton
Date: Sun, 14 Jan 1996 00:00
53 lines
2937 bytes
In article <821564328snz@pdlmail.demon.co.uk>, Peter Disdale
<Pete@pdlmail.demon.co.uk> writes

>The mail starts normally (gets accepted etc.) but
>a few packets down the way everything grinds to a halt, symptomatic
>I thought of data loss and the SMTP client and server getting out of
>sync.

Forget the "out of sync"... but the description sounds like packet loss
somewhere - possibly on the demon network. Are you doing this at a busy
time ? What machine is at the other end of the connection ?

>>          while (count-- != 0)
>>              outportb (base + THR, *dp->data++);

the problem with the 16550A is that it tells you that it is empty, but
unfortunately as soon as you stuff in one byte it says that it is no
longer empty, but there's this nice FIFO you'd like to use. Hence this
tacky approach of knowing the FIFO length and just pushing stuff in.

>This last loop worries me; my PC uses a 16550A (and presumably has an
>OUTPUT_FIFO_SIZE of 16).  So what is going to happen if the modem's
>HWM is crossed during this loop?

the control signal will change

>  And worse still, if said HWN is
>within 16 bytes of the end of the buffer?  The modem will dutifully
>drop CTS, and KA9Q will take no notice.

it would be a pretty stupid modem which assumed that the other end would
stop immediately it asked. This will be the main reason for the
handwaving about exactly where the HWM is in relation to the end of the
buffer - they don't want to encourage you to exploit this distance.

I'm not saying your modem does not live this dangerously, but 16550s
have been around all decade, so people are aware of their amusing little
quirks (like sending 16 bytes more than you'd perhaps wish)

>  Whether or not interrupts
>are enabled (I *think* they're still disabled after 'asyNvec' calls
>'asyint()'), the "change of RS232 status" interrupt will not be
>processed by KA9Q until any pending transmitter interrupts have been
>serviced, because the latter have a _higher_ priority. The result?
>Data loss and perhaps an unhappy modem :(

if you are getting data loss on outgoing data then you would be able to
tell this from the retransmit figures for the socket.

-- 
richard                      Richard Clayton         T U R N P I K E  Ltd
                                                     tel: +44 1306 747747
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM
Technical Details
Message-ID: <y0YnHMAB5T+wEAtl@turnpike.com>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <821135729snz@pdlmail.demon.co.uk>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10bb05,b29a5bcea6e71e5
X-Google-Attributes: gid10bb05,public
From: Richard Clayton <richard@turnpike.com>
Subject: Re: SMTP implementation in KA9Q
Date: 1996/01/14
Message-ID: <y0YnHMAB5T+wEAtl@turnpike.com>
X-Deja-AN: 135384708
distribution: world
x-nntp-posting-host: pillar.turnpike.com
references: <821135729snz@pdlmail.demon.co.uk>
organization: Turnpike Ltd
mime-version: 1.0
newsgroups: demon.ip.developers