The attached diff adds 2 ftp functions. I read the
README.SUBMITTING_PATCH and went thru all the steps, but there are no
tests for ftp, and I didn't understand how to update the docs. So if
someone would like to help me with that, great.
Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of
strings) to store the conversation, and an int that indicates the next
element in first dimension the array. I modified ftp_putcmd and
ftp_getresp to add what gets sent/recvd in the conversation. And lastly
I added ftp_get_resp which returns the 3 digit return code from the
server of the last command sent, and ftp_get_conv (which I would not be
opposed to changing the name of, that's just what I came up with) that
returns the ftp conversation as an array. Both functions must be called
before ftp_close (or ftp_quit) because it frees the resource.
The array I defined is 2500x4096. 4096 was already there as the
FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it could
get that bad. :/ So I was thinking that maybe I should add a optional
flag on ftp_connect on where or not to trace the conversation? Thoughts?
Jess
Hi Jesse,
2500*4096 = 10M on ftpbuf would be too much for the user who is not
interested in this functionality.
It should be allocating the memory dynamically instead of hardcoding the
size to 2500.
This need to happen only when requested, may be some option argument to
ftp_connect whether to track the ftp conversation.
With regards
Kamesh Jayachandran
On Wed, 15 Dec 2004 21:47:09 -0700, "Binam, Jesse"
Jesse.Binam@simplot.com said:
The attached diff adds 2 ftp functions. I read the
README.SUBMITTING_PATCH and went thru all the steps, but there are no
tests for ftp, and I didn't understand how to update the docs. So if
someone would like to help me with that, great.Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of
strings) to store the conversation, and an int that indicates the next
element in first dimension the array. I modified ftp_putcmd and
ftp_getresp to add what gets sent/recvd in the conversation. And lastly
I added ftp_get_resp which returns the 3 digit return code from the
server of the last command sent, and ftp_get_conv (which I would not be
opposed to changing the name of, that's just what I came up with) that
returns the ftp conversation as an array. Both functions must be called
before ftp_close (or ftp_quit) because it frees the resource.The array I defined is 2500x4096. 4096 was already there as the
FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it could
get that bad. :/ So I was thinking that maybe I should add a optional
flag on ftp_connect on where or not to trace the conversation? Thoughts?Jess