Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=NkRoHTtpdjUow8MAB5m4Ny2krqLyAFbIKjo7/frQo8JD0e5f1EDHDZd86uKHHbtDLYPRa51VL3wj6+eCvxF5wuaUCx74KcJedRehsbEz3ZgfgUUNyEjfm1WT6T8qNqACWfJ3KbhEDTiPbd16XEaZJssZJVPnHfRBHUtg04lJxbU=
Message-ID: <4e89b4260412161351614246b@mail.gmail.com>
Date: Thu, 16 Dec 2004 16:51:37 -0500
Reply-To: Wez Furlong <kingwez@gmail.com>
To: "Binam, Jesse" <Jesse.Binam@simplot.com>
Cc: Kamesh Jayachandran <kameshj@fastmail.fm>, internals@lists.php.net
In-Reply-To: <5367F26C013DE8429873569307F6F4A382F963@OCC01MX023.na.simplot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <5367F26C013DE8429873569307F6F4A382F963@OCC01MX023.na.simplot.com>
Subject: Re: [PHP-DEV] ftp_get_resp & ftp_get_conv functions
From: kingwez@gmail.com (Wez Furlong)

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 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
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>