Re: Eu socket issues (was problems with webutils)
On 5 Aug 2001, at 15:27, Ted Fines wrote:
<snip>
> So on to the next one, right? Actually, this project has been going really
> well
> the last couple of days; I will post everything to Rob's web site once it's
> worth posting.
>
> Here's the current problem:
> I prepare to FETCH a message by first finding out how big it is, using the
> "A89
> FETCH 1 RFC822.SIZE" command, which in turn says it is 88,420 bytes. (This
> command says Fetch the RFC822 size of message 1 in the currently selected
> mailbox.) The A89 part can be ignored; read about it in the IMAP RFC--its
> just
> an indexer. The large size is correct; there are two attachments. Since IMAP
> adds some extra header/trailer lines, a pad the receive buffer with 1k (tried
> 2k,3k,4k,5k,10k) to make sure I don't get a buffer overflow error. Believe
> me,
> 1k is plenty.
>
> I then FETCH a message with this command: "A66 FETCH 1 RFC822.PEEK". This
> tells
> the IMAP server to send me message #1 in the currently selected mailbox, but
> not
> to flag it as Seen.
>
> This command results in the RFC822 message being sent, then trailed by this
> footer: "A66 OK FETCH completed". I run a packet sniffer while I issue these
> commands, so I am certain I am correct about my program's determination of the
> exact message size, that I am getting the message, and that I am getting this
> exact footer (see URL of .gif of sniffer results below).
>
> But tcp4u doesn't return what was sent. The RFC822 body is all there, but at
> the end, where the footer is supposed to be, I get some garbage characters
> instead (see URL at end for pics).
>
> What is really odd to me about this is that for this I am using tcp4u's
> receive_until_str function. This function says "receive data on this
> socket until string x comes in, or y seconds go by (a timeout value),
> whichever comes first. This function will either return the received data,
> and
> a resultcode indicating success; or whatever data it did get, and a result
> code
> indicating timeout or buffer overflow, or something else. In my case, x is
> the
> footer I mentioned above. I have double-double-double-checked mine for a dumb
> typo.
>
> The result code coming back from tcp4u is success, not timeout, and it
> comes back very fast, so it couldn't be timing out, since for my tests I've
> been
> setting the timeout insanely high (5 minutes). This means tcp4u must be
> reading
> the footer in the data stream.
>
> So I look at the tcp4u returned data sequence, and like I said, the body of
> the
> message seems OK, but then there is some junk at the end, instead of the
> footer.
> This is not the first time in the program I am using tcp4u_receive_until_str,
> and the times before, it works fine--I see the footer message at the end. (I
> changed tcp4u to show the buffer before it exits its function, so I could see
> what it is returning, just before its return statement.)
>
> Any ideas? This just isn't right, but I don't know why tcp4u is sending
> back junk. Here is a URL with three images: 1 is the sniffer results; and 2-3
> are what tcp4u is returning, in ascii code format and as characters.
>
> <http://www.macalester.edu/~fines/tcp4u_problem.html>
I didn't have much luck with the tcp4u_receive_until_str(), for the same
reasons, and don't use it. Besides, what if the return string was nested
inside an email about IMAP codes, like this one? What is the string you
want it to return on? Is it "A66 OK"? Also, did you check the first byte of the
nested return sequence to see if it is the actual length of the IMAP return
(minus everything after the end string including the return string length)? Here
is a section of working code to illustrate what i mean:
if tcp4u_is_data_avail(sock) then
sock_receive = tcp4u_receive(sock,1000,0)
if sock_receive[1] > 0 then
databuffer = databuffer & sock_receive[2][1..sock_receive[1]]
end if
end if
Kat
|
Not Categorized, Please Help
|
|
