🚀 go-pugleaf

Hi Owen,

For now, I'm looking for a solution regarding the while loop in the
receiveFile() method on the server app.  Shall we solve that problem
first?
I need some way of making it exit the loop. Somehow it has to get that
EOF signal.

Your idea for creating a whole new socket for uploading and downloading
of files is a good one.  I hadn't thought of that. Perhaps the next
version release I'll delve into implementing that idea.

One other thought did cross my mind, this particular posting to the
newsgroup is getting rather lengthy and the subject matter has had its
twists and turns from the original posting.  Should we continue our
conversation away from the newsgroup? Or do you want to continue as is?
I'm easy either way.

I'm just not sure others would find what we have to say from this point
on of any interest.

Alan

Owen Green wrote:
> 
> "Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
> news:3D25C73F.4D8D94E0@hfx.eastlink.ca...
> 
> >
> > As mentioned earlier, the way the scenario goes on the client side is:
> >
> > 1)in uploadFile() create a File object
> > 2)get the files size and transmit that value to the server app
> > 3)the server app determines if there is enough space in the users home
> > directory
> >   to accomodate the file.
> > 4)I need a mechanism on the client side to wait for the reply from the
> > server
> >   as to whether to proceed or not, thus the request_workerThread. It
> > will wait
> >   five second intervals, up to 30 seconds total for a reply. After 30
> > seconds, if there
> >   is no reply from the server, request_workerThread suspends itself
> > again
> >   until it is called.
> A call to read() on the input stream will block until it has data, and by
> using the socket timeout, will handle that aspect as well. If you are to
> process you could then either create a new thread or using a thread pool of
> some sort, giving it the File reference and let it get on with the upload in
> the background.
> 
> I would still be tempted to have the client and server establish a secondary
> socket for the data transfer though; that makes it much easier to code for
> situations like stopping the transfer gracefully, allowing for resumes etc.
> 
> hope I've got the right end of the stick,
> Owen