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
