QUESTIONS;
do we want to handle event management as a utility function set up or server method?
epoll() is my suggestion for how we handle multiple clients , as this allows us to have an easier management system through out the project, allowing us to add and remove clients with ease and listen to incoming on the server socket . epoll also does not require a constant refreshing of an array of structs which can cause significant overhead.
epoll() management would be best handled by one person overall and we could label with comments where we assume it to be needed if we choose to do it this way should we need to label it through out the project.
This means a epoll instance must be created , then add the server socket to the Epoll instance lastly wait for events and handle them.
Catching events seems to be 3 stage, check if server incoming, check if client incoming otherwise we handle POLLERR or alike or simply close client.
Handling events can be simplified and cut into 3 pieces , These handling of events do not need to be done by who is in charge of basic epoll structure and basic set up for forwarding to the next progression stage.
- Server side incoming, set up new client ( for this a handle new client function should exist)
- Client side incoming we will need to read to a buffer and send message for parsing and handling in otherways. (for this we could use a handle message method in a message class) to start with we can keep it simple and send to a placeholder.
- Else close clauses may require clean up . (this could be a multi use function).
There are multiple events that can be added , POLLIN would state that there is new data to be handled, POLLERR would be suggestive of an error that must be handled on the server side.
QUESTIONS;
do we want to handle event management as a utility function set up or server method?
epoll() is my suggestion for how we handle multiple clients , as this allows us to have an easier management system through out the project, allowing us to add and remove clients with ease and listen to incoming on the server socket . epoll also does not require a constant refreshing of an array of structs which can cause significant overhead.
epoll() management would be best handled by one person overall and we could label with comments where we assume it to be needed if we choose to do it this way should we need to label it through out the project.
This means a epoll instance must be created , then add the server socket to the Epoll instance lastly wait for events and handle them.
Catching events seems to be 3 stage, check if server incoming, check if client incoming otherwise we handle POLLERR or alike or simply close client.
Handling events can be simplified and cut into 3 pieces , These handling of events do not need to be done by who is in charge of basic epoll structure and basic set up for forwarding to the next progression stage.
There are multiple events that can be added , POLLIN would state that there is new data to be handled, POLLERR would be suggestive of an error that must be handled on the server side.