Sockets (java)

Pelvis

I have to create a P2P chat application, I am familiar with the very basics of client/server sockets and threads etc. My issue is, for this app the "server's" role is just registering new clients and send back a list of active clients. When it comes to sending messages the server program should not be involved.

So, I'm a little confused, would each peer in this scenario have its own Socket AND ServerSocket? One for listening for incoming connections and one to connect to other 'clients'? This seems messy, I'm sure I'm missing something!!

Pelvis

Okay so far I have a Peer class where objects need to be instantiated with a srvPort they're gonna listen for connections on (among other things), this object is sent to the chat server which adds it to an array list of peers and maintains this list, providing it to new Peers who can then call the appropriate getters for the srvPorts to initiate connections etc etc.

Am I on the right track?

Sheeps

Think protocol. When a user sends a message, do you want to close the socket or do you want to wait for a response? It might be easier (with out building in heart beats etc) to simply open and close a connection with every message. The idea would be that you have a server socket bound to a protocol port for incoming messages. Then when a user wants to send a message to a peer that they have obtained from your p2p client registry, you open up a new client socket to send that message, and close it after. If the user wants to reply to that user, they will simply open up the client socket to your server socket and send the message, as the first user did.

The difficulty lies in correlating the messages with a conversation, because you could potentially have a number of clients connecting and sending messages to your server socket. Maybe include a header or conversation key or something. Your server socket should spawn off a new thread to handle the request which will be responsible for dealing with the incoming message.

Using a persistent connection adds a layer of difficulty, in particular over public networks where you could potentially have firewall rules killing inactive connections with out notifying either socket of the disconnect, which is why heartbeats and keep alive packets are essential, you'd still be faced with a lot of the same problems of correlation, and having to create new threads to deal with incoming requests, but you could simply write a response to the server socket, or visa versa with the client socket.

In a peer to peer network you only really want to centralise the clients of the p2p network and rely on protocol to do the rest. Alternatively you can search for clients using UDP by broadcasting your client to tell the world you're out there. Other clients in your network could send your client a list of other users they're aware of. You would still use TCP to communicate.

Pelvis

Thanks for the response. I should add that this is part of an assignment, and as far as I understand it there is no requirement for it to run outside the localhost, so won't have to worry about firewalls etc. I should probably clarify that though... :pac:

So far I've created the Server that each peer keeps needs to initially register with. In my head I was going to keep the socket open once this was done for processing any further messages, for instance a peer would use the server to get an updated list of active peers, but coordinating these messages seemed like a pain! So now once a peer is registered I close the socket, if the peer wants to update its active client list then it opens a new socket to the server, in both cases the first message from the peer is a string indicating to the server what request to process, e.g. "REGISTER" or "UPDATE", and I use a switch statement on the server side to handle these. Would there be a better way to do this? It seems rather crude.

So right now when a Peer is initiated, the constructor calls a register method to register with the server. Then I start a new Thread and in it create a server for the Peer to wait for incoming messages. This all seems to be working as expected. Once this is done a method is called on the Peer to send a message, this iterates over the Peer list, creating a new Thread for each and connecting to that peer's server. Here is where I fell down, when I write a message and hit enter it isn't being printed to the server side console. I was tearing my hair out over it last night. So, will need to look at it with fresh eyes tonight.

I had intended to keep the sockets open for messages between peers, though your suggestion of closing the socked and letting the recipient open a socket to the senders server to send a response sounds like it may be better?