Agreed. That was a bad idea.
After I slept on it, I regreted sending that, cause the default memory
limit is 8M (with the exception of the cli sapi). With no option on
whether or not to do the trace and 2500x4096 being a 10M buffer, I
imagine just calling ftp_connect would put you over your memory limit.
So I will change it to allocate the memory dynamically, and an optional
parmeter to ftp_connect on whether or not to do the trace at all.
But now I need some advise from you experts...
I can't imagine getting a 4k response or sending a 4k command on the
control channel of an FTP session. So that is a lot of unused memory, on
the other hand, that's how big the input/output buffers are and without
knowing what the length of the longest response/command is until the
whole conversation is finished, if my string buffer is to small, it will
either truncate the string (with proper bounds checking) or create the
potential for a buffer overflow. I could check the length of the string
and if it is longer than the current length of the string array, then
allocate enough memory to hold it, increasing the length of the element
for all the other strings. In which case I would think it appropriate to
#define MAX_RESP_LENGTH to prevent potential for a DOS.
Also allocating N+1 elements every time a command is sent or a response
is received would create a ton of overhead because wouldn't I would have
to allocate the new buffer, then copy the current buffer in to it
resulting in a serious performance hit?
Regretfully ignorant,
Jess
-----Original Message-----
From: Kamesh Jayachandran [mailto:kameshj@fastmail.fm]
Sent: Thursday, December 16, 2004 6:57 AM
To: Binam, Jesse; internals@lists.php.net
Subject: Re: [PHP-DEV] ftp_get_resp & ftp_get_conv functions
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
Check out either the smart_str API or simply log the conversation to a
user-supplied stream.
--Wez.
On Thu, 16 Dec 2004 11:02:43 -0700, Binam, Jesse
Jesse.Binam@simplot.com wrote:
Agreed. That was a bad idea.
After I slept on it, I regreted sending that, cause the default memory
limit is 8M (with the exception of the cli sapi). With no option on
whether or not to do the trace and 2500x4096 being a 10M buffer, I
imagine just calling ftp_connect would put you over your memory limit.
So I will change it to allocate the memory dynamically, and an optional
parmeter to ftp_connect on whether or not to do the trace at all.But now I need some advise from you experts...
I can't imagine getting a 4k response or sending a 4k command on the
control channel of an FTP session. So that is a lot of unused memory, on
the other hand, that's how big the input/output buffers are and without
knowing what the length of the longest response/command is until the
whole conversation is finished, if my string buffer is to small, it will
either truncate the string (with proper bounds checking) or create the
potential for a buffer overflow. I could check the length of the string
and if it is longer than the current length of the string array, then
allocate enough memory to hold it, increasing the length of the element
for all the other strings. In which case I would think it appropriate to
#define MAX_RESP_LENGTH to prevent potential for a DOS.Also allocating N+1 elements every time a command is sent or a response
is received would create a ton of overhead because wouldn't I would have
to allocate the new buffer, then copy the current buffer in to it
resulting in a serious performance hit?Regretfully ignorant,
Jess-----Original Message-----
From: Kamesh Jayachandran [mailto:kameshj@fastmail.fm]
Sent: Thursday, December 16, 2004 6:57 AM
To: Binam, Jesse; internals@lists.php.net
Subject: Re: [PHP-DEV] ftp_get_resp & ftp_get_conv functionsHi 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 nextelement 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 fromthe 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
Jesse,
By the way, I would guess that reallocating memory in the area of a few K
would be negligible to sending FTP commands over the network. So in this
case I wouldn't worry about it too much and I agree with Wez suggestion to
look at smart_str API.
Andi
At 04:51 PM 12/16/2004 -0500, Wez Furlong wrote:
Check out either the smart_str API or simply log the conversation to a
user-supplied stream.--Wez.
On Thu, 16 Dec 2004 11:02:43 -0700, Binam, Jesse
Jesse.Binam@simplot.com wrote:Agreed. That was a bad idea.
After I slept on it, I regreted sending that, cause the default memory
limit is 8M (with the exception of the cli sapi). With no option on
whether or not to do the trace and 2500x4096 being a 10M buffer, I
imagine just calling ftp_connect would put you over your memory limit.
So I will change it to allocate the memory dynamically, and an optional
parmeter to ftp_connect on whether or not to do the trace at all.But now I need some advise from you experts...
I can't imagine getting a 4k response or sending a 4k command on the
control channel of an FTP session. So that is a lot of unused memory, on
the other hand, that's how big the input/output buffers are and without
knowing what the length of the longest response/command is until the
whole conversation is finished, if my string buffer is to small, it will
either truncate the string (with proper bounds checking) or create the
potential for a buffer overflow. I could check the length of the string
and if it is longer than the current length of the string array, then
allocate enough memory to hold it, increasing the length of the element
for all the other strings. In which case I would think it appropriate to
#define MAX_RESP_LENGTH to prevent potential for a DOS.Also allocating N+1 elements every time a command is sent or a response
is received would create a ton of overhead because wouldn't I would have
to allocate the new buffer, then copy the current buffer in to it
resulting in a serious performance hit?Regretfully ignorant,
Jess-----Original Message-----
From: Kamesh Jayachandran [mailto:kameshj@fastmail.fm]
Sent: Thursday, December 16, 2004 6:57 AM
To: Binam, Jesse; internals@lists.php.net
Subject: Re: [PHP-DEV] ftp_get_resp & ftp_get_conv functionsHi 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 nextelement 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 fromthe 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