[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [JDEV] Win client, File Transfers, invite tag..




I think this is a great idea, but I have a few suggestions.  Why don't you
call it "uumessagetransfer" instead of "wintransfer", as that would be a
more accurate description of what it does.

Also, instead of using a random number to idenfity file transfers, maybe
an md5 hash of the original file would be better.

One thing to consider is how it handles sending enormous files.  It would
be desireable that a file transfer could be started without reading in the
entire file in advance, or converting it to uuencoded format in advance.
Is it possible to precisely predict the uuencoded size from the original
size?  If not, then perhaps using the original files size instead of the
uuencoded files size in the protocol would allow the file to be uuencoded
bit by bit while it was transfered.

As for packet sizes, larger packets might actually be better than smaller
packets, but of course there will be some middle point that works out the
best.

The reason I think this might be the case is that smaller packets will
require more processing by the server.  Processing time is probably more
valuable than memory.  Also, memory might not be saved at all by smaller
packets because you would probably just end up sending more in a given
period of time.  This would mean more processing on the server, as well as
more memory use because of the increased overhead from the information
with each packet.

In fact, a packet size of 60k or so might be better.  Many files could be
sent in one packet, which would make it quite efficient.

This brings up another question, how fast to send packets?  If they are
sent as fast as possible, they could pile up at the server, which wouldn't
be nice for the server.  But if you have replies being sent, you could
time them to get an idea of how fast things are going through and pace the
rate at which you send them.  But this adds complication.

Mabye replies and pacing should be an optional feature for advanced
implemenations.

Just some thoughts,

Quetzalcoatl Bradley
qbradley@csc.uvic.ca