OpenEuphoria

Re: Eu socket issues (was problems with webutils)

• Posted by Ted Fines <fines at macalester.edu> Aug 05, 2001
• 419 views

Kat wrote:
<snip>
     if ret != TCP4U_SUCCESS then
         printf(1, "tcp4u_send error '%s'\n", tcp4u_error_string(ret))
     end if
     -- see if we logged in OK
     sleep(1)
     result=ReadServer(asock_conn[2])

            ^
There is the problem, just by glancing at the code.
global function ReadServer(object sock) expects the nested sequence, not 
the [2] part.
But i am surprised there is no error msg.
<snip>

Kat,

What I posted is slightly different from the code you posted...So that 
isn't...wasn't the problem, as it would have definitely resulted in a type 
check error.

The (dumb) problem was that my mail server didn't understand my requests as 
it didn't have the right CRLF combo on the end... I made a constant 
MYLF={10}, and now I am past that (dumb) problem.

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>

Thanks all,
Ted Fines
Macalester College