Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20041220004154.02589a10@localhost>
Date: Mon, 20 Dec 2004 00:42:54 -0800
To: Wez Furlong <kingwez@gmail.com>,"Binam, Jesse" <Jesse.Binam@simplot.com>
Cc: Kamesh Jayachandran <kameshj@fastmail.fm>,internals@lists.php.net
In-Reply-To: <4e89b4260412161351614246b@mail.gmail.com>
References: <5367F26C013DE8429873569307F6F4A382F963@OCC01MX023.na.simplot.com>
 <5367F26C013DE8429873569307F6F4A382F963@OCC01MX023.na.simplot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] ftp_get_resp & ftp_get_conv functions
From: andi@zend.com (Andi Gutmans)

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 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
> >
> >
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php