Threads - Server Side

[solomon13000]

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]

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]

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

--

what mechanism would you suggest to use to identify the state of the
socket?

 

[Lew]

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();
}
}

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().

 

[Gordon Beaton]

what mechanism would you suggest to use to identify the state of the
socket?

It's right there in the second paragraph.

/gordon

--

 

[solomon13000]

It's right there in the second paragraph.

/gordon

--

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]

"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]

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."

Yep.

 

[solomon13000]

Yep.

If I were to do this while(cs != null) will it work?

 

[Lew]

If I were to do this while(cs != null) will it work?

No.