I am developing a chat system in Java and evaluating two different approaches for handling communications:
Each chat server will support a maximum of 10 clients, meaning the system will not be highly populated. Given these constraints, I am analyzing whether adopting the Event-Driven Model would provide meaningful advantages over the simpler SocketChannel approach.
My current server looks like this:
package Chat;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SocketChannel;
import java.nio.channels.spi.SelectorProvider;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;
public class SimpleServerChannel {
private List<SocketChannel> clientChannels = new CopyOnWriteArrayList<>();
private List<Chat_Interface> clientInterfaces = new ArrayList<>();
public void start() {
try (CustomServerSocket serverChannel = new CustomServerSocket(SelectorProvider.provider(), clientChannels, clientInterfaces)) {
serverChannel.socket().bind(new InetSocketAddress(5000));
serverChannel.configureBlocking(false);
System.out.println("Server is listening on port " + serverChannel.socket().getLocalPort());
ByteBuffer buffer = ByteBuffer.allocate(1024);
clientChannels = serverChannel.getClientChannels();
clientInterfaces = serverChannel.getClientInterfaces();
while (true) {
SocketChannel clientChannel = serverChannel.accept();
Iterator<SocketChannel> iterator = clientChannels.iterator();
if (clientChannel != null) {
clientChannel.configureBlocking(false);
clientChannels.add(clientChannel);
System.out.printf("Client %s connected%n", clientChannel.socket().getRemoteSocketAddress());
}
while (iterator.hasNext()) {
SocketChannel client = iterator.next();
try {
buffer.clear();
int bytesRead = client.read(buffer);
if (bytesRead == -1) {
System.out.printf("Client %s disconnected%n", client.socket().getRemoteSocketAddress());
clientChannels.remove(client);
client.close();
} else if (bytesRead > 0) {
buffer.flip();
byte[] data = new byte[buffer.remaining()];
buffer.get(data);
String message = String.format("%s", new String((data), StandardCharsets.UTF_8));
for (SocketChannel otherClient : clientChannels) {
buffer.clear();
buffer.put((message).getBytes());
buffer.flip();
while (buffer.hasRemaining()) {
otherClient.write(buffer);
}
}
}
} catch (IOException e) {
System.out.printf("Client %s disconnected due to error%n", client.socket().getRemoteSocketAddress());
clientChannels.remove(client);
client.close();
}
}
}
} catch (IOException e) {
throw new RuntimeException(e);
}
}
public List<SocketChannel> getClientChannels() {
return clientChannels;
}
public List<Chat_Interface> getClientInterfaces() {
return clientInterfaces;
}
}
My question is if I have to switch with the second approach, or for my needs(mentioned earlier), keeping this approach is enough for understanding low level network programming and build a small feature?
My question is if I have to switch with the second approach, or for my needs(mentioned earlier), keeping this approach is enough?
Without reviewing the code in detail, no, you do not have to change approach. By setting the channels to non-blocking, you avoid getting stuck trying to service a client that is unready while other clients have data waiting. Busy-looping through the clients, attempting to service each one in turn and being appropriately accepting of failures, can provide service to all clients. That for a certain number of clients and a certain data volume, which is probably more than you will saturate with 10 clients operated interactively by humans.
But that is dreadfully inefficient at the server, which is a consideration if the server has anything else to do at the same time (which yours apparently does). It also has latency issues that might become noticeable to human users even at modest load. And it scales poorly.
We can't judge in advance whether the system's performance will be good enough for you, both because
And we can't judge whether your approach is enough for your learning objectives, either, because, again, we don't know what those are, and, again, I bet you don't know exactly what those are either. Certainly I would expect you to learn more by implementing an approach based on Selectors. I'm uncertain whether that's what you mean by an "event-driven model", but it is certainly among the better-performing, better-scaling, conventional approaches to I/O multiplexing such as you are trying to do.