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

["Thomas Charron" <tcharron@nermail.ups.com>]

> From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of
> qbradley@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
> best.

	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.
all change..

> 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'
sceme..

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

	See my last reply.. ;-P


--
Thomas Charron
United Parcel Service
Northeast Region
"Moving at the speed of a T3 Trunk Line!"