I've been playing with your code to try to figure out how to start work on a MUD in Java. Pretty much the only thing you're missing
for your foundation as far as I need is a way to talk about clients and their interaction with the server. I can see you are on the
way with the packets you've added, but what you need to do is get a way to determine how to handle multiple users logged on at
once. I have some code from somewhere else that does this to some extent, but it is extremely excessive and the problems
I have with it are too widespread(to other classes that use it) to be able to fix it. The packets for the type of server I want are all strings, so having different types doesn't help me, though there are many other kinds that would need various types. Basically what I'm saying is that you should come up with a server-client interaction that just uses strings(or numbers for more simple type) to get a handle on what you need to do to accept more complicated inputs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> but what you need to do is get a way to determine how to handle multiple users logged on at once
I'm not sure exactly what you mean by this. When you extend the class nfc.server.Server, you can have multiple simultaneous logons because you're overriding the processConnection() function and creating a new worker thread and then returning to the accept-wait loop for connections. The worker thread should handle all interaction with the client...
Maybe what you mean is "a better way for changing the state of the server as multiple clients are doing things" ? Did you have anything particular in mind? I'm open to ideas... The only problem I see with writing code to change the internal server state is that the internal state is going to be highly dependent on what you want the server to do in most cases. If you're a mail server you'll need a much different state than a MUD and I don't really have any ideas for what could be common between them as far as internal state....
I'm always interested in ideas though. If you know what you want I'd be willing to try to take a crack at it.
> Basically what I'm saying is that you should come up with a server-client interaction that just uses strings(or numbers for more simple type) to get a handle on what you need to do to accept more complicated inputs.
If you take a look at a StringPacket that's exactly what it does. For instance lets say you are doing a simple chat server, your code would look (something) like this for your Worker thread class (obviously this isn't working code... and I added something new that I added to the StringPacket class that I didn't have before, the getParamsAfter function which I'll be checking in shortly)
public class worker extends Thread
{
static worker[] workers = new worker[MAXUSERS];
static chatroom[] rooms = new chatroom[MAXROOMS];
private int index;
public worker()
{
index = assignUniqueIndex();
allworkers[index] = this;
}
public void run()
{
PacketHandler handler = new PacketHandler();
handler.addPacketListener(new PacketAdapter(ChatClient.MESSAGE) {
public void fireAction(Packet p)
{
String room = p.getParam(0);
String message = p.getParamsAfter(1);
int theroom = Integer.parseInt(room);
if (rooms[theroom].hasUserJoined(index))
{ rooms[theroom].sendMessage(ChatClient.MESSAGE + " " + index + " " + message); }
else
{ sendMessage(ChatClient.ERROR + " " + "Can't send message to a room you haven't joined"); }
}
});
handler.addPacketListener(new PacketAdapter(ChatClient.JOIN) {
public void fireAction(Packet p)
{
String room = p.getParam(0);
rooms[Integer.parseInt(room)].addUser(index);
}
});
handler.addPacketListener(new PacketAdapter(ChatClient.PART) {
public void fireAction(Packet p)
{
String room = p.getParam(0);
rooms[Integer.parseInt(room)].removeUser(index);
}
});
}
}
In any event I'm glad that someone at least has taken an interest in this. Let me know if you have any ideas or things I can do to help you out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ugh I didn't <PRE> my code... sorry about that... And I had another question, were you talking about client->server interaction stuff maybe? Because at this point all the code I have is oriented towards server to client stuff and not client to server.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been playing with your code to try to figure out how to start work on a MUD in Java. Pretty much the only thing you're missing
for your foundation as far as I need is a way to talk about clients and their interaction with the server. I can see you are on the
way with the packets you've added, but what you need to do is get a way to determine how to handle multiple users logged on at
once. I have some code from somewhere else that does this to some extent, but it is extremely excessive and the problems
I have with it are too widespread(to other classes that use it) to be able to fix it. The packets for the type of server I want are all strings, so having different types doesn't help me, though there are many other kinds that would need various types. Basically what I'm saying is that you should come up with a server-client interaction that just uses strings(or numbers for more simple type) to get a handle on what you need to do to accept more complicated inputs.
> but what you need to do is get a way to determine how to handle multiple users logged on at once
I'm not sure exactly what you mean by this. When you extend the class nfc.server.Server, you can have multiple simultaneous logons because you're overriding the processConnection() function and creating a new worker thread and then returning to the accept-wait loop for connections. The worker thread should handle all interaction with the client...
Maybe what you mean is "a better way for changing the state of the server as multiple clients are doing things" ? Did you have anything particular in mind? I'm open to ideas... The only problem I see with writing code to change the internal server state is that the internal state is going to be highly dependent on what you want the server to do in most cases. If you're a mail server you'll need a much different state than a MUD and I don't really have any ideas for what could be common between them as far as internal state....
I'm always interested in ideas though. If you know what you want I'd be willing to try to take a crack at it.
> Basically what I'm saying is that you should come up with a server-client interaction that just uses strings(or numbers for more simple type) to get a handle on what you need to do to accept more complicated inputs.
If you take a look at a StringPacket that's exactly what it does. For instance lets say you are doing a simple chat server, your code would look (something) like this for your Worker thread class (obviously this isn't working code... and I added something new that I added to the StringPacket class that I didn't have before, the getParamsAfter function which I'll be checking in shortly)
public class worker extends Thread
{
static worker[] workers = new worker[MAXUSERS];
static chatroom[] rooms = new chatroom[MAXROOMS];
private int index;
public worker()
{
index = assignUniqueIndex();
allworkers[index] = this;
}
public void run()
{
PacketHandler handler = new PacketHandler();
handler.addPacketListener(new PacketAdapter(ChatClient.MESSAGE) {
public void fireAction(Packet p)
{
String room = p.getParam(0);
String message = p.getParamsAfter(1);
int theroom = Integer.parseInt(room);
if (rooms[theroom].hasUserJoined(index))
{ rooms[theroom].sendMessage(ChatClient.MESSAGE + " " + index + " " + message); }
else
{ sendMessage(ChatClient.ERROR + " " + "Can't send message to a room you haven't joined"); }
}
});
handler.addPacketListener(new PacketAdapter(ChatClient.JOIN) {
public void fireAction(Packet p)
{
String room = p.getParam(0);
rooms[Integer.parseInt(room)].addUser(index);
}
});
handler.addPacketListener(new PacketAdapter(ChatClient.PART) {
public void fireAction(Packet p)
{
String room = p.getParam(0);
rooms[Integer.parseInt(room)].removeUser(index);
}
});
}
}
In any event I'm glad that someone at least has taken an interest in this. Let me know if you have any ideas or things I can do to help you out.
Ugh I didn't <PRE> my code... sorry about that... And I had another question, were you talking about client->server interaction stuff maybe? Because at this point all the code I have is oriented towards server to client stuff and not client to server.
i was talking more the client to server interaction, cause i'm not seeing how the client 'talks' to the server.