Niklas Gustavsson wrote:
James Im wrote:
Could there be a way to support both models? let's see:
For normal connection without ssl you could use mina.
client <---> [ mina - ftpserver ]

For ssl you could have 2 models:
1) one mode would use ssl-nio:
client <---> [ mina - sslFilter - ftpserver ]

2) another compatibility-mode for pure java 1.4
client <---> [ blocking ssl  - mina - ftpserver ]

In this last mode, the blocking ssl server would decrypt the data stream
and feed it to mina. From the [mina-ftpserver] point of view this would
work like a regular ftp session.

Could this be implemented as a filter in MINA? Would this method work
with MINA?

http://forum.java.sun.com/thread.jspa?threadID=592674&tstart=0

I don't know if this would/can work. Filters are not supposed to block.


The communication between the blocking ssl and mina could be a regular
socket connection. I don't know if it could be a VmPipeConnector too
(but that's an implementaion detail).

If it's a filter this would not be required, right?


I don't know if a filter is the best solution. You should look at the
tennis example that uses VmPipeConnector/VmPipeAcceptor.

These classes allow intra VM communication through a pseudo port. The
port is not a real port so no socket are created.

Both SocketAcceptor, VmPipeAcceptor and even DatagramAcceptorDelegate
extends BaseIoAcceptor.

So the idea would be to use a VmPipeAcceptor instead of a SocketAcceptor
when starting the ftpserver in 1.4 compatibility mode.
Then as I said before, the blocking ssl server would feed to bytes to
the VmPipeAcceptor (via a VmPipeConnector).

This design would be performant as no extra sockets are created. It
would also be clean: when designing the ftpserver on top of mina you
don't have to take into account extra stuff to be able to support 1.4.

This could work for ftpserver 1.0.

Please take a look at the tennis example.

_________________________________________________________________
Find dine dokumenter lettere med MSN Toolbar med Windows-pc-søgning: http://toolbar.msn.dk

Reply via email to