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