Just a few suggestions about the design.
1. You don't need the server to know about the view.
2. On the server keep a list of sessions. When a client connects for the first time it sends a session containing session ID 0. Then the server sends back a new allocated session ID.
3. A session is a class containing a few facts like the client name, session ID and last time of access (you want to kill an inactive session after a while)
4. Every message from the client to the servers always includes the session ID. For this you might implement a Message class.
5. The message can contain: requests for session (maybe with authentication), commands (list users for example) and messages for other users.
5. Messages from a client to other clients are distributed back by the server.
6. Messages are handled by threads created for that purpose or reused from a pool.
7. The GUI (View) uses the client but the client doesn't need the GUI to run.
Identified actors: Server, Client, Session, Message
Inside the server you have an "Incoming Message Dispatcher" and an "Outgoing Message Dispatcher". they get the incoming messages, distribute them to working threads and then distribute back to Clients the answers.
To keep it simple you can use UDP in the beginning.
Have fun
You might attack Yahoo!'s market share with this