1. re: Problems with webutils
- Posted by Ted Fines <fines at macalester.edu> Aug 02, 2001
- 440 views
Kat, Thanks for the reply & code snippet. I think I'm missing something basic with this. 1) In your code, you quit when you receive a '13'. Does '13' signify end of transmission? 2) Why do you drop the '10' character--won't that elminate returns? For example, the IMAP command A FIND ALL.MAILBOXES "*" might return quite a few lines (however many mailboxes the user has), such as: * MAILBOX INBOX * MAILBOX Accounts * MAILBOX ArcServe * MAILBOX Cisco * MAILBOX Corporate Time * MAILBOX DNS_DHCP * MAILBOX Euphoria * MAILBOX Linux * MAILBOX Novell * MAILBOX PMDF * MAILBOX Robots * MAILBOX Verisign * MAILBOX WASTEBASKET * MAILBOX deadletter a OK FIND ALL.MAILBOXES completed Won't it be bad if I delete out all of the \n characters? Isn't a '13' and a \n sent at the end of every line? Or more simply, how do I know how much data came back, and when I can stop looping for it? Thanks, Ted Kat wrote: It's a little time consuming to run, but it's fast enough, and it took no time to write it. I use that same function in the SMTP section (port25), and almost the same code in the irc client (any port). Specifying one byte at a time is safest, it won't hang waiting for anything if the connection is broken, but it's also the slowest if everything is working perfectly. I do not close the port until after the logout in any of the cases: -- sign off properly SendToServer(sock_connect[2],"QUIT\r\n") -- listen for +OK for a little while -- close the port after +OK or timeout -- clean up tcp4u -- clean up this application -- end The gotcha in IMAP, as i understand RFC 1203, is that the client-server can change the command/handshake eol terminator string from crlf to whatever they want. I tried to look up the latest data at www.imap.org but somebody broke the internet here and i can't reach many websites since about midnight. Kat
2. re: Problems with webutils
- Posted by gertie at ad-tek.net Aug 02, 2001
- 412 views
On 2 Aug 2001, at 16:05, Ted Fines wrote: > > > Kat, > > Thanks for the reply & code snippet. I think I'm missing something basic > with this. > 1) In your code, you quit when you receive a '13'. Does '13' signify end > of transmission? POP3 lines are ended with at least one one CRLF. > 2) Why do you drop the '10' character--won't that elminate returns? I wanted the function to return the data, and didn't need the line terminator, whatever it is. It does return the CRLFCRLF terminator for large *blocks* of data, like an email which can contain the CRLF in the text. I haven't looked at it in a while, but i should add a switch for not deleting those chars within the blocks, if i use it for anything but checking for the presence of email.. > For example, the IMAP command > A FIND ALL.MAILBOXES "*" > might return quite a few lines (however many mailboxes the user has), such > as: > * MAILBOX INBOX > * MAILBOX Accounts > * MAILBOX ArcServe > * MAILBOX Cisco > * MAILBOX Corporate Time > * MAILBOX DNS_DHCP > * MAILBOX Euphoria > * MAILBOX Linux > * MAILBOX Novell > * MAILBOX PMDF > * MAILBOX Robots > * MAILBOX Verisign > * MAILBOX WASTEBASKET > * MAILBOX deadletter > a OK FIND ALL.MAILBOXES completed > > Won't it be bad if I delete out all of the \n characters? Isn't a '13' and > a \n sent at the end of every line? In IMAP, as i understand it, you *could* have a 10, or a 13, or a 10,13 or a 13,10. Like i said, i couldn't get to imap.org, but there should be a function to recognise what the terminator will be, and i expect you'll want to toss out the terminator to parse the command parameters in the lines. So grabbing one line at a time from the winsock cache, processing it, and returning for the next line is just easier than writing your own cache, reading gobs into your program, hoping it doesn't hang with a net interruption, making the user wait instead of scrolling the window with data they can read while you process the incoming, etc etc. FINDALL will return data untill it says it is done, with an OK, and all the intermediate lines are the mailbox names, separated by the terminator. you code knows it is in FINDALL block of code and will know how to parse the data stream up to that OK, cause that's the way you wrote it. It's the same way with all the commands. When you get back "* MAILBOX DNS_DHCP\n\r", you don't store the name of the box as that do you? No, you strip off the "\n" and "\r". Just as easy to do it as you have it in your paws in the read() function, simply drop it on the floor and return(), than to do it later. But either way is ok. > Or more simply, how do I know how much data came back, and when I can stop > looping for it? In my code, i ask winsock if there is any data waiting (i ask tcp4u actually), and if there is data, there is at least one byte, so i ask for it, and then ask if there is another one. That way i am not asking for data that wasn't sent, thereby hanging the program. If there is a net connection, and you lose the eol terminator, but get another command string, that's how you can tell if you missed a eol, there can be only one command per line. The reason i do not loop based on recieving a command tho is simple, what if there is a word in the command parms that is a command word in *another syntax*? And if you recieve such a word, and loop till you get the params you expect, and the server isn't rfc compliant, or the specs change, you must rewrite code. My isps are not POP3 compliant, no telling what i will get after a "+OK", for instance, so i haveto know what i am expecting, regardless of what the english phrases say was sent. One isp sends email totals for one command, and the other doesn't. One kept "upgrading" to a server that would not allow header retrieval. The other one periodically aborts everything and tells me the rest of the world is gone. It pays to cover your posterior in these things. Kat