Changed FTPD.

[Jake Janovetz]

Unfortunately, in many of my hooks, this leads to more complicated
code and my code allocating the same buffer as before.

   Jake


On Fri, Jan 12, 2001 at 11:07:50AM +0300, Sergei Organov wrote:
> Jake,
> 
> I left hooks in place.
> 
> As for hooks implementation, I'd suggest to use fixed size buffer and call
> hook 'write' routine multiple times while data are being received, the same
> way it works when writing to a file. This is usual way to do such things and
> doesn't depend on file size at all. Apparently open/close (or begin/end) hook
> routines will be required in this case.
> 
> It does make hook routines more complex in some cases though, but then they
> could decide themselves to allocate whatever buffer they need in 'open' hook,
> fill it, then process it in 'close' hook.
> 
> Sergei.
> 
> Jake Janovetz <janovetz at uiuc.edu> writes:
> > I'd like that, but (to my knowledge) FTP doesn't supply the size of
> > a file before it transmits it.  It could be realloc'ed, but that
> > gets expensive.  Any better ideas?
> > 
> >    Jake
> > 
> > 
> > On Thu, Jan 11, 2001 at 12:55:57PM -0700, OUTWATER ~ KEITH J /5G3110 wrote:
> > > Ditto.  They're real handy.  
> > > 
> > > BTW Jake, is there any pratical way to eliminate the requirement to specify the 
> > > buffer size for the hooks?  Could it be dynamically allocated and be allowed to 
> > > grow to the system memory limits?
> > > 
> > > Keith
> > > 
> > > > 
> > > > This all sounds very good to me!  (as long as you keep the FTP 
> > > > hooks in there, I'm happy -- I don't know about others, but I
> > > > do use them)
> > > > 
> > > >    Jake
> > > > 
> > > > 
> > > > On Thu, Jan 11, 2001 at 10:05:44PM +0300, Sergei Organov wrote:
> > > > > Hello,
> > > > > 
> > > > > I've finished a bunch of changes to the RTEMS FTP server. If the changes 
> > > seem
> > > > > to be promising, I'll be glad to submit them to RTEMS maintainers.
> > > > > 
> > > > > Here is the list of changes:
> > > > > 
> > > > > - use pool of pre-created threads to handle sessions instead of
> > > > >   creating/deleting threads on the fly
> > > > > - LIST output is now similar to what "/bin/ls -al" would output, thus
> > > > >   FTP clients such Netscape are happy with it.
> > > > > - LIST NAME now works (both for files and directories)
> > > > > - added support for NLST, CDUP, and MDTM FTP commands to make more FTP 
> > > clients
> > > > >   happy 
> > > > > - keep track of CWD for every session separately
> > > > > - ability to specify root directory name for FTPD in configuration table. 
> > > FTPD
> > > > >   will then create illusion for FTP clients that this is actually root
> > > > >   directory.
> > > > > - ignore options sent in commands, thus LIST -al FILE works and doesn't try 
> > > to
> > > > >   list "-al" directory.
> > > > > - buffers are allocated on stack instead of heap where possible to eliminate
> > > > >   malloc/free calls (avoid possible heap fragmentation troubles).
> > > > > - drop using of task notepad to pass parameters - use function arguments
> > > > >   instead
> > > > > - use snprintf() instead of sprintf() everywhere as the latter is unsafe
> > > > > - use of PF_INET in socket() instead of AF_INET
> > > > > 
> > > > > Here are ftp clients I've tried new FTPD with
> > > > > (all of them running on Debian GNU/Linux 2.2):
> > > > > 
> > > > > Lftp 2.1.10
> > > > > NcFTP 2.4.3
> > > > > Netscape 4.75
> > > > > ftp
> > > > > mc 4.5.49
> > > > > 
> > > > > BR,
> > > > > Sergei Organov.
> > > >