1. Eu socket issues (was problems with webutils)
- Posted by Ted Fines <fines at macalester.edu> Aug 03, 2001
- 429 views
Hi all, OK, so now I'm trying sockets stuff using eutcp4u. Kat sent me this function: global function ReadServer(object sock) sequence recievedline,sock_receive recievedline = "" while tcp4u_is_data_avail(sock[2]) do sock_receive = tcp4u_receive(sock[2],1,1) if sock_connect[1] != TCP4U_SUCCESS then printf(1, "tcp4u_connect error '%s'\n", {tcp4u_error_string(sock_connect[tcp4u_ret])} ) exit end if if equal(sock_receive[2],{10}) then sock_receive[2] = "" end if if equal(sock_receive[2],{13}) then return recievedline else recievedline &= sock_receive[2] end if end while -- tcp4u_is_data_avail(sock[2]) do return"" end function -- checkserver So here's a little test code I wrote, to connect to the server. -- open socket and connect asock_conn=tcp4u_connect("141.140.1.2",NULL,143) if asock_conn[1] != TCP4U_SUCCESS then printf(1, "tcp4u_connect error '%s'\n", {tcp4u_error_string(asock_conn[tcp4u_ret])} ) abort(1) end if -- process login message data. if I don't have it sleep -- here, sometimes 'result' comes back blank. Eu too fast -- for its own good? sleep(1) result=ReadServer(asock_conn) puts(1,result & "\n") -- send login credentials ret = tcp4u_send_sequence(asock_conn[2],"A LOGIN " & name & " " & password & "\n") 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]) puts(1,result & "\n") But here's the problem: result, after "see if we logged in OK" is ALWAYS empty. Nothing comes back. Why not? I am sure the login request is getting sent correctly, or ret would come back with an error response. I've tried sending the login command a second and a third time, and looking for a result. Nothing ever comes back. I have ended my A LOGIN command above with "\r\n" and "\n" with the same result. So it seems I have a connection, and I seem to be sending data OK, yet nothing comes back??? Help!
2. Re: Eu socket issues (was problems with webutils)
- Posted by gertie at ad-tek.net Aug 03, 2001
- 436 views
On 3 Aug 2001, at 9:11, Ted Fines wrote: > > Hi all, > > OK, so now I'm trying sockets stuff using eutcp4u. Kat sent me this > function: > > global function ReadServer(object sock) > sequence recievedline,sock_receive > recievedline = "" > while tcp4u_is_data_avail(sock[2]) do > sock_receive = tcp4u_receive(sock[2],1,1) > > if sock_connect[1] != TCP4U_SUCCESS then > printf(1, "tcp4u_connect error '%s'\n", > {tcp4u_error_string(sock_connect[tcp4u_ret])} ) > exit > end if > if equal(sock_receive[2],{10}) then > sock_receive[2] = "" > end if > if equal(sock_receive[2],{13}) > then > return recievedline > else > recievedline &= sock_receive[2] > end if > end while -- tcp4u_is_data_avail(sock[2]) do > return"" > end function -- checkserver > > So here's a little test code I wrote, to connect to the server. > -- open socket and connect > asock_conn=tcp4u_connect("141.140.1.2",NULL,143) > if asock_conn[1] != TCP4U_SUCCESS then > printf(1, "tcp4u_connect error '%s'\n", > {tcp4u_error_string(asock_conn[tcp4u_ret])} ) > abort(1) > end if > -- process login message data. if I don't have it sleep > -- here, sometimes 'result' comes back blank. Eu too fast > -- for its own good? > sleep(1) > result=ReadServer(asock_conn) > puts(1,result & "\n") > -- send login credentials > ret = tcp4u_send_sequence(asock_conn[2],"A LOGIN " & name & " " & > password & "\n") > 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. > puts(1,result & "\n") > > But here's the problem: result, after "see if we logged in OK" is ALWAYS > empty. Nothing comes back. Why not? I am sure the login request is > getting sent correctly, or ret would come back with an error response. > I've tried sending the login command a second and a third time, and looking > for a result. Nothing ever comes back. I have ended my A LOGIN command > above with "\r\n" and "\n" with the same result. > > So it seems I have a connection, and I seem to be sending data OK, yet > nothing comes back??? Should i post the entire email checker? I didn't get to retrieving the email yet, just getting a header list. I haven't had time to do *any* coding lately. Kat
3. Re: Eu socket issues (was problems with webutils)
- Posted by Ted Fines <fines at macalester.edu> Aug 05, 2001
- 421 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
4. Re: Eu socket issues (was problems with webutils)
- Posted by Kat <gertie at PELL.NET> Aug 06, 2001
- 440 views
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