-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add TCP server and client classes #34
Conversation
sockaddr_in new_socket_address{}; | ||
socklen_t new_addr_len = sizeof(new_socket_address); | ||
// accept, create a new socket descriptor to handle the new connection with client | ||
this->socket_fd_ = accept(this->server_fd_, (sockaddr*) &new_socket_address, &new_addr_len); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's happening here is that the socket file descriptor that is used for communication is not the same as the socket that was opened and used for accepting connections. Instead, we create a new socket for the first incoming request from a client.
* @brief Connect the TCP socket to its counterpart (client / server) | ||
* @details This method should be called after `open()` and may be blocking (for the case of a server) | ||
*/ | ||
virtual void connect() = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not respect the interface defined in ISocket. Would it be appropriate just to call connect()
at the end of open()
? Based on the simple test case it seems it would suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I guess we could do it like that as well, but then open()
becomes blocking for the tcp server
Putting this on hold for now |
This is now active again but the comment above about doing the connection in |
Could you see if there is a |
There isn't.
Yes, but I expect controllers to create tcp clients, not servers. The server always has to be up before the client. So if we assume that we will most often use clients and only rarely create servers ourselves, I can just move the code from |
Let's do it like that for now, to keep a consistent interface, and then see if the blocking is an issue in practice. |
Description
Again, a slightly large PR due to the definition of three new classes. The
TCPSocket
class itself is also pure virtual because TCP communication is a communication-based protocol, hence between sending/receiving, we need aconnect
step. For the server, this is a blocking operation (see docstrings). Apart from the fact that connection needs to be established with a few extra steps, the TCP implementation is very similar to UDP.Review guidelines
Estimated Time of Review: 15 minutes