File Upload Server

[Frederic Bregier]

Hello,

I think both solutions can be efficient, and are not so different in fact.

The first one will rely on the split on the tcp/ip stack, also you are right
when
you write that you need to take care of the buffer. In fact, stay with a
fixed length
buffer and write as many buffers as you need. To be functional, you need to
send
first the global size of the file, such that the server will wait for all
pieces
and assemble them in order. For the size, see at the end.
Advantage: quick and simple to implement.
Disadvantage: no control on send and receive, that is to say the client does
not know
if the server is ok until the last message...

The second one could be the first one you say but with an approach using
business.
You will rely on a "business" approach. The server and client will exchange
some buffers with some extra information in front of each. For instance:
- first message from client = the global length buffers that will be sent
plus 
  first buffer (if first buffer is the last one, length = buffer length)
- next messages from client = length of current buffer plus buffer
The server could answer for each packet an acknowledge.
Also you can even (if needed) add a MD5 control on each packet.
Advantage: you have the control on send and receive (you can even re-send a
packet
if there is a problem - md5 control - or restart from a specific point if
transmission
was wronk - like with some FTP server where they restart from a previous
position).
Disadvantage: a little bit more complicated but quite useful to control the
behaviour.

Now on the size of the buffer, I would suggest something bigger than 1024
bytes.
In fact, there is two size to mix: the optimal size from filesystem and the
optimal size from the network. For me the first one is about 4 to 32KB, the
second
is between 16 to 64KB. Those values have to be validated by yourself.
For me, I set 32KB or 16KB which seems a reasonable tradeoff between network
and filesystem.

However, all of this depend on your final goal: what kind of files, what
length,
what kind of security and control, what kind of protocol (opened, standard -
like
ftp or similar - or proprietary)...

HTH,
Frederic

-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/File-Upload-Server-tp1689933p1690089.html
Sent from the Netty User Group mailing list archive at Nabble.com.