Re: Java

From: andreas (newsgroup_at_kinell.ch)
Date: 09/22/04 

Date: Wed, 22 Sep 2004 20:28:12 +0200

> I haven't got any threads running yet, am I correct in thinking that
> I'll need threads to run multiple clients?

yes: if you want the server to handle multiple clients, you need threads.

> I'm also a little bit unsure about how I should layout the classes.
> Ie: should I have a client class, server class, and connection class??

a client class and a server class makes a lot of sense.
later both the client and the server class will have their own main()
method.
so you start a server on a computer as a standalone, and the client on
another.

the connection class:
it is not needed. i do use a ConnectionManager class which offers
openConnection(), closeConnection(), send and receive.
but note, that a server might handle a connection differently than a client.

you could start without. your client would then look more or less like this:

public class Client{

static final int SUCCESS = 1;
static final int ERROR = 0;
private Socket socket;
private DataOutputStream out;
private DataInputStream in;

public Client(//arguments){
    //create socket
    //bind streams
}
public int send(String message){
    //maybe convert the string to byte[]
    out.write(message);
    return SUCCESS;
}
public int receive(byte[] byteArray){
    //in.read returns the number of bytes read and writes the data into the
byteArray
    return in.read(byteArray);
}

public static void main(//arguments){
    Client client = new Client(//arguments);
    //read something from input
    client.send(//input);
    client.receive(//answer);
}

}

note that this is not a complete client but a framework.
this is how it could look like. also, it is very convenient
to be able to receive messages unblocked (note that receive() here
will block until data is available). you would then start a new thread
with a run method looking more or less like this:

run(){
while(true){
    client.receive();
    //print the received data to the screen
}

>> you should now design a chat-protocol, which both server and client
>
> I'm not too sure what you mean by this. Do you mean a class to handle
> messages to and from the server?
>

no, the general design. maybe you want to interpret some comands instead
of just printing them on the screen.
have a look at RFC2812 for the specifications of the IRC protocol

andreas

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • Re: bug with sending null elements of DataSet[] ?
    ... On client side, call webmethod like this: ... So, on server side, I expected to see a DataSet array with one element, where that element contains null. ... This should have been a big hint to the client, but apparently, it was not. ... public int ID ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)