the client side consists of client data handling and message handling.
The client will have its own class that manages and stores client information. (see client class creation task).
Basically it will contain things like name , socket_fd/id flags for various potential requirements one example being admin rights. all of this data will be used to manage each individual instance of a client.
i suggest message handling to be managed through its own message class. this will allow for clearer task separation and program management in general.
The message class (see message class creation) will contain most of the message handling requirements such as validation, sending and receiving of messages etc. the message class will receive data coming in from the client socket and the active a client will "announced" by epoll()
utility functions and data .
a map or defined global variables of strings can be used to help manage predictable irc protocol .
one utility function could be , when epoll() informs us of which client fd has a message incoming we could have a read to buffer utility function that then will pass this newly formed data/string to the message class methods.
another utility function could also be a simple parser of this message , but if this is smart or required is yet to be researched. simpler is to have the message class handle all parsing .
the client side consists of client data handling and message handling.
The client will have its own class that manages and stores client information. (see client class creation task).
Basically it will contain things like name , socket_fd/id flags for various potential requirements one example being admin rights. all of this data will be used to manage each individual instance of a client.
i suggest message handling to be managed through its own message class. this will allow for clearer task separation and program management in general.
The message class (see message class creation) will contain most of the message handling requirements such as validation, sending and receiving of messages etc. the message class will receive data coming in from the client socket and the active a client will "announced" by epoll()
utility functions and data .
a map or defined global variables of strings can be used to help manage predictable irc protocol .
one utility function could be , when epoll() informs us of which client fd has a message incoming we could have a read to buffer utility function that then will pass this newly formed data/string to the message class methods.
another utility function could also be a simple parser of this message , but if this is smart or required is yet to be researched. simpler is to have the message class handle all parsing .