File Upload Server

manish_iitg excellencetechnologies08 at gmail.com
Mon Dec 22 08:53:02 EST 2008


Hello,

Thanks for the quick reply. 

I will go with the second approach as it has more control over the whole
process. Thanks for buffer size recommendation. I was not aware of that. 
MD5 is also a good suggestion. I will try to implement this, and post it on
the wiki space created. 




Frederic Bregier wrote:
> 
> 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
> 

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




More information about the netty-users mailing list