Code design problem in chat

sometimes im stumbling over architecture questions in my projects. i have a server/client chat, basic structure is like this:

I think you forgot to hit paste :0 ??? ???

im very, very sorry:
sometimes events occur so that the textarea loses focus and i press enter for newline … :-/

but my question, i try to keep it short:

my chat (server/client) is constructed in basic of these modules (note that the server has a chat-gui too, only difference is, that he can be host):

the gui class gets a interface-relation to the server-class (respectively the client class) to send it events like text typed for sending, disconnect via gui etc.
vice versa the server-class gets an interface-relation to the gui to append incoming messages, add new guests etc.

now i want to write a protocol-class. this class shall define how the commandos for all actions are calles and how to put them in a string-stream for the server/client-class to send. main goal should be that you can easily modify the protocol without touching the other classes.
(the communication is done via simple text-streams like
“msg||greetings all||nameOfSender”)

but all ways of doing it have some less beautiful aspects:

  1. i take for every actin (sending message, changing font-attributes, disconneting) an own method in the protocol class, which server/client has to inherite or to implement.

example:
gui-class gets textinput and calls server.broadCast(msg).
the server inherited how to do this.
=> this can produce many, many nonsense-like methods

  1. i make the protocol class like a static tool class
    there i define besides the constantes for the stream-commands a method for melting the commands with the delimiter (preparing a whole sending-stream) and
    for cutting them in parts for receiving.
    the server class then could only have one method which has a large if/else tree for every request

example:
gui wants to send text:
server.sendRequest(Protocol.MESSAGE, “foo”, this.name)
the server knows with the first parameter what to do and calls teh protocol methods for preparing the stream out of those elements.
=> ugly strategy cause the gui needs access to the protocol-class and is not forced to send only valid parameters.

not so short as i mentioned, but i hope my problem is clear …