[JDEV] Win client, File Transfers, invite tag..
tcharron at nermail.ups.com
Fri Mar 26 20:01:56 CST 1999
> From: owner-jdev at jabber.org [mailto:owner-jdev at jabber.org]On Behalf Of
> qbradley at csc.UVic.CA
> Subject: 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.
Ordinarily, yes, I would use something like that. But do to the current
status of client development, I figured something that I KNEW I could use
that would identify it without messing with something else someone else may
be developing was much more prudent..
> Also, instead of using a random number to idenfity file transfers, maybe
> an md5 hash of the original file would be better.
Either way would work, but a random number is easier.. ;-P
> 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.
Yes, this would be the best.. This was merely done as a quick 'I can
develop file transfer REALLY easy with this'. And it also a VERY reliable
way to transfer binary data via a text transfer.. Also, the exact file size
is used to tell if it all worked.. Again, merely a quickie to do it..
> 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
It's a toss up between proccesser time and memory performance.. Smaller
packets leadto less memory usage, but more 'packets'. Getting to small
would be silly, but I was figuring 10-50 k at a chunk..
> 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.
I would say for future reference, I'd let the server at some point give a
'prefered packet size'. This would allow the transport to give that
particular data itself.. But as I said, this is a quickie, so it'll prob.
> 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.
See above.. Currently, my sceme (from a client side) doesn;t allow more
then one file per send (But multiple sends at a a TIME are ok). Again,
scratch it off to a quickie..
> 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.
Exactly why I had the idea of replies, but that also get's in the way. I'm
figuring ONE message sent that the user is offline, then a question as to if
you want to send it as an offline message, not using the 'client-server'
> Mabye replies and pacing should be an optional feature for advanced
See my last reply.. ;-P
United Parcel Service
"Moving at the speed of a T3 Trunk Line!"
More information about the JDev