🚀 go-pugleaf

Hi John,

This is a repost of my reply.  I tried cancelling what I had sent earlier,
but for some reason your server won't service my request to cancel the
message.  So, I'm resending it with some additional info.

The first method you explain is the one I am making use of.  I am familiar
with how the nio package works, but that is a discussion for another time.
I'm trying to focus on the former method.  As you pointed out, one generally
sets up a ServerSocket that listens on a particular port. In my case port
5000.  When a client logs on, a new thread is spawned.  I get that already.
My server app does exactly that.  What I wanted to do next was assign port
5001 to another ServerSocket that every client uses to upload/download
files. But
as I said earlier, there may be times when more than one client is trying to
upload/download files at the same time. That's when I thought a queue might
be appropriate.

Proceedure:
1) The client sends a request to upload a file.
2) The client's request goes into the queue.
3) The queue, running on it's own thread, would continually check to see if
the port is open or not.  If the port is being used, then the client next in
line in the queue just has to wait for the port to open up.
4) Once the port 5001 becomes available again, the next client in the queue
is given the go ahead to proceed with the upload.

I hope this is a little clearer.  Does this approach look ok?

The reasoning behind all this is that originally, as each Client thread was
created I would call getInputStream() and getOutputStream() on the Socket.
I needed to keep the connection open for purposes other than just moving
files, so I couldn't just close the connection.  As a result, when ever I
did try to upload or download a file it generally was incomplete or
corrupted in some way.
So, it dawned on me that a seperate connection must be setup to open a
seperate port with another ServerSocket, connect with the client, move the
file, then close the connection and ServerSocket all in one go.  This way,
the process doesn't interfere with the main connection of the client with
the server.

Alan

"John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
news:xn0dphn9w893v7001@newsgroups.borland.com...
> On 11/7/2004 at 9:50:02 AM, Alan Shiers wrote:
>
> > Does it make sense to use a particular port as a shared resource
> > for a particular purpose?  In my case, I have my server app where
> > I want to make available a particular port that clients can use to
> > upload/download files.  However, the possible problem arises that
> > several people may be trying to upload/download files on this port
> > at the same time.  So, I'm thinking of implementing a queue to test
> > for the availability of the port and process each clients request
> > in turn.
>
> I see the problem here.  That is not the normal way that multi-threaded
> TCP/IP server applications works.  The normal way for these to work is for
> the server to create a ServerSocket, and listen for connections using
> ServerSocket.accept().  When a client connects, accept() returns a regular
> (client) Socket, which the server uses to communicate with the client.
>
> If the processing for a client is more or less instantaneous, such as with
> something like a time server that just writes out the current time and
> closes the connection, then you can do that in the main thread.  But if
> the processing might take some time, you start a separate thread to
> process the client's request, and return to listening on the ServerSocket.
> Here is the basic structure of a typical server (missing details such as
> exception handling):
>
>    serverSocket = new ServerSocket( WELL_KNOWN_PORT );
>    while ( ! shuttingDown ) {
>       Socket clientSocket = serverSocket.accept();
>       Thread thread = new ClientThread( clientSocket );
>       thread.start();
>    }
>
> The well-known port that you use for the server socket is just used to
> establish the connection.  The client socket will use a different port,
> which will be automatically allocated by the system.  You do not have to
> worry about that detail.
>
> Note that with the java.nio package introduced in Java 1.4, there are ways
> of serving multiple clients in the same thread, so you would not need to
> create a separate thread for each client.  If you need to handle many
> simultaneous clients, you might want to look into that.  It is much more
> complex than the above approach, but it can also result in significant
> performance improvements.
>
> -- 
> Regards,
>
> John McGrath [TeamB]
>
> ---------------------------------------------------
> Before sending me e-mail, please read:
>     http://www.JPMcGrath.net/newsgroups/e-mail.html