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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Thursday, December 16, 2004 6:57 AM > To: Binam, Jesse; [EMAIL PROTECTED] > 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" > <[EMAIL PROTECTED]> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
