🚀 go-pugleaf

 In article <838295414snz@wash.demon.co.uk>
  John Washington <john@wash.demon.co.uk> said:-

[snip]

>coding style.  Currently I have a problem with a 900K
>mail that is waiting for me on 'punt'.  (Don't you just
>love it when you mail a request to a server that gives
>you no indication of how much it's going to hit you with?
>But that's another story).  Ka9q receives this mail ok,
>but then seems to "get stuck" at the end.  It won't even
>respond to commands like 'so' or 'ex'.  Luckily I have an
>external modem, and dropping power on it instantly frees
>up ka9q.  However, it seems that the final part of the
>SMTP handshake hasn't been done, because next time I log
>on the mail is still waiting on Demon for me.
>
>Anyone else had this problem, any clues where exactly in
>the source the problem might be?  I'm aware that it may be
>due to the delay while copying the temp file being too long
>for the client, but I don't see why that should lock up
>other processes.

This is probably irrelevent as the atari version is way behind in 
updates. However, the effects you describe match the problem exactly.

Are more and more SMTP server sockets opened as time progresses? A new 
socket seems to be opened for each punt containing mail [fine], plus 
another each time the punts attempt their periodical connections. This 
is bad because each of these "extra" sockets start receiving the same 
data from scratch so nothing actually gets to finish and system 
resources eventually give out. Manually stopping the smtp listener 
after the initial punt connect stops this. I assume the bug is in the 
listener code - it should not be initiating another server for a punt 
to which it is already connected?


__

Guy Harrison

guy@swampdog.demon.co.uk