The code bellow is a server code that will continuesly wait for a
vector object from the client side. There are many clients that will
be connected to the server. Must I use threads to handle the many
clients?. Is it advisable to implement threads and why?
import java.net.*;
import java.util.*;
import java.io.*;
public class GandhiServer2
{
ServerSocket ss;
Socket cs;
Vector ht;
ObjectInputStream ois;
public GandhiServer2()
{
try
{
ss = new ServerSocket(9000);
cs = ss.accept();
while(cs.isConnected() == true)
{
ois = new ObjectInputStream(cs.getInputStream());
ht = (Vector)ois.readObject();
System.out.println(ht);
cs = ss.accept();
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
public static void main(String[] args)
{
new GandhiServer2();
}
}
Regards.
Gordon Beaton - 07 Oct 2007 12:34 GMT
> The code bellow is a server code that will continuesly wait for a
> vector object from the client side. There are many clients that will
> be connected to the server. Must I use threads to handle the many
> clients?. Is it advisable to implement threads and why?
You don't have to use a thread per client to handle multiple
simultaneous clients, but it's an easy solution that's ok for a simple
server or one that only needs to handle a few clients at a time. The
alternative is Selector.select() which can handle many clients in a
single thread.
Note that cs.isConnected() does not do what you think it does, it will
not tell you when the client has disconnected. Any of the various
mechanisms for reading from the socket will though.
I'd also suggest that you move the accept() call *outside* the client
loop, i.e. use two nested loops: an outer loop to accept connections,
and an inner loop to handle the connected client. You should also
close every client socket when you've finished handling the client or
the server will fail after some number of clients have been handled.
/gordon
--
solomon13000@gmail.com - 07 Oct 2007 16:11 GMT
> > The code bellow is a server code that will continuesly wait for a
> > vector object from the client side. There are many clients that will
[quoted text clipped - 20 lines]
>
> --
what mechanism would you suggest to use to identify the state of the
socket?
Gordon Beaton - 07 Oct 2007 17:08 GMT
> what mechanism would you suggest to use to identify the state of the
> socket?
It's right there in the second paragraph.
/gordon
--
solomon13000@gmail.com - 07 Oct 2007 17:24 GMT
> > what mechanism would you suggest to use to identify the state of the
> > socket?
[quoted text clipped - 4 lines]
>
> --
In the second paragraph I see
"Note that cs.isConnected() does not do what you think it does, it
will
not tell you when the client has disconnected. Any of the various
mechanisms for reading from the socket will though."
Gordon Beaton - 07 Oct 2007 17:30 GMT
> "Note that cs.isConnected() does not do what you think it does, it
> will not tell you when the client has disconnected. Any of the
> various mechanisms for reading from the socket will though."
So... any mechanism that reads from the socket will tell you whether
it's still connected. Take your pick.
You're already using ObjectInputStream.readObject(), I'll guess it
throws an EOFException when the socket is closed.
/gordon
--
Lew - 07 Oct 2007 17:34 GMT
>>> what mechanism would you suggest to use to identify the state of the
>>> socket?
[quoted text clipped - 10 lines]
> not tell you when the client has disconnected. Any of the various
> mechanisms for reading from the socket will though."
Yep.

Signature
Lew
solomon13000@gmail.com - 07 Oct 2007 17:39 GMT
> solomon13...@gmail.com wrote:
> >>> what mechanism would you suggest to use to identify the state of the
[quoted text clipped - 18 lines]
>
> - Show quoted text -
If I were to do this while(cs != null) will it work?
Lew - 07 Oct 2007 17:43 GMT
>> solomon13...@gmail.com wrote:
>>>>> what mechanism would you suggest to use to identify the state of the
[quoted text clipped - 15 lines]
>
> If I were to do this while(cs != null) will it work?
No.

Signature
Lew
Lew - 07 Oct 2007 16:59 GMT
> The code bellow is a server code that will continuesly wait for a
> vector object from the client side. There are many clients that will
[quoted text clipped - 38 lines]
> }
> }
Get that work out of the constructor!
Create a service method, e.g., "run()", to do the work.
Constructors are for construction, only.
public static void main(String[] args)
{
GandhiServer2 server = new GandhiServer2();
server.run();
}
Why are you using the hoary Vector class instead of ArrayList?
It looks like all your instance variables should be method variables inside run().

Signature
Lew