1. Eu socket issues (was problems with webutils)
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
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)
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)
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
