I can look for a single "." on the last line, but there are lots of other
occasions where the server may repond with a single line, or multiple lines.
Right now, I just pause for a while at every socket read to wait for more
data. If it doesn't come after a couple seconds, I assume there is no more
to be had. This works, but is rather slow.
Does anybody have any ideas on how to determine the number of lines of data
to be retrieved from a socket?
>I'm writing an application in Rexx that retreives eMail from POP3 servers.
>I'm having trouble with the code that actually gets the data from the socket.
> My problem is that I don't know how to efficiently tell if more data is
>coming from the server.
When you register (USER and PASS command) you can see he size of
each message. You can check this by telnetting to 110 port of a POP server.
For example - part of session:
===
+OK OS2PopS 2.02 02 Jun 97 ready <1080.112...@timur.sax.mmbank.ru>
user timurk
+OK Password required for timurk
pass YjdtkkF
+OK timurk has 1 message(s) (8261 octets).
list
+OK 1 8261
1 8261
.
===
So I have 1 message with size of 8261 bytes
With best regards,
Timur Kazimirov
-- Remove all "z" from my address to reply
>I'm writing an application in Rexx that retreives eMail from POP3 servers.
>I'm having trouble with the code that actually gets the data from the socket.
> My problem is that I don't know how to efficiently tell if more data is
>coming from the server.
>
>I can look for a single "." on the last line, but there are lots of other
>occasions where the server may repond with a single line, or multiple lines.
>Right now, I just pause for a while at every socket read to wait for more
>data. If it doesn't come after a couple seconds, I assume there is no more
>to be had. This works, but is rather slow.
>
>Does anybody have any ideas on how to determine the number of lines of data
>to be retrieved from a socket?
If you look at RFC1725, which defines the POP3 protocol, you'll see that
the first <crlf>.<crlf> sequence *must* be the end of the message data.
Any line beginning with a period will be byte-stuffed. That is, it'll
have an additional period stuffed onto the beginning. So, you'll also
need to look for <crlf>..<something else>, and change it to
<crlf>.<something else>. This is done to any line beginning with a period
by the server. It's the same thing you have to do when sending via SMTP,
as well.
In C/C++, you can use strstr() to look for the end sequence in the
received data.
For doing the translation of byte stuffing, a somewhat messy loop
involving strstr(), strncpy(), and a pointer variable will do. C/C++ are
not good languages for string manipulation. Another approach would be to
tokenize the data by line separation, which would make it easier to strip
the period from the front of any line, if it exists (for if there is one
period, there must be another).
--
- Mike
Remove 'spambegone.net' and reverse to send e-mail.
> On Thu, 23 Dec 1999 19:26:48 -0800 (PST), Casey Bralla wrote:
>
> >I'm writing an application in Rexx that retreives eMail from POP3 servers.
> >I'm having trouble with the code that actually gets the data from the socket.
> > My problem is that I don't know how to efficiently tell if more data is
> >coming from the server.
> If you look at RFC1725, which defines the POP3 protocol, you'll see that
> the first <crlf>.<crlf> sequence *must* be the end of the message data.
> Any line beginning with a period will be byte-stuffed. That is, it'll
> have an additional period stuffed onto the beginning. So, you'll also
> need to look for <crlf>..<something else>, and change it to
> <crlf>.<something else>. This is done to any line beginning with a period
> by the server. It's the same thing you have to do when sending via SMTP,
> as well.
I have a cpile of REXX scripts which illustrate the algorithm. I wrote
them to fix a longstanding bug in Post Road Mailer (which didn't byte
stuff correctly).
See:
http://www.tavi.co.uk/os2pages/innoval/prdotfix.zip
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..