libsocket::unix_dgram_client would unlink the socket's path #66

Activity

1. dermesser commented on Oct 11, 2019

   

   dermesser

   on Oct 11, 2019

   Owner

   More actions

   I'm afraid I don't quite understand the point you are trying to make. Are you suggesting that the unix_dgram_client::unix_dgram_client() constructor should unlink() the socket path after connecting?
2. ancloud-teach commented on Oct 12, 2019

   

   ancloud-teach

   on Oct 12, 2019

   Author

   More actions

   I'm afraid I don't quite understand the point you are trying to make. Are you suggesting that the unix_dgram_client::unix_dgram_client() constructor should unlink() the socket path after connecting?

   it is not my mean.
   I just do an example in your project, libsocket\examples++\unix_dgram_client.cpp.
   unix_dgram_client cl("/tmp/clsock") and cl.sndto(logmsg, "/tmp/srvsock") must be different, otherwise the client would not be work well.
   In you unix_dgram_client's constructor, you had unlink the socket path. But the path may be had already create by unix server.

   int main(void) {
       std::string sock = "/tmp/srvsock";
       ......
       try {
           libsocket::unix_dgram_client cl("/tmp/clsock");
           cl.sndto(logmsg, sock);
           ......
       } catch (const libsocket::socket_exception& exc) {
           std::cerr << exc.mesg;
       }
       return 0;
   }
   
3. dermesser commented on Oct 12, 2019

   

   dermesser

   on Oct 12, 2019

   Owner

   More actions

   Ah I now understand where the socket is unlinked
   You mean that in this example "/tmp/clsock" may have already been created by the server? Yes, but if the client wants to bind to it, it is still ok to unlink it first. After all, the server should bind to a different path than the client.

   I feel like I still don't really understand the issue you describe.
4. ancloud-teach commented on Oct 17, 2019

   

   ancloud-teach

   on Oct 17, 2019

   Author

   More actions

   for example,
   SERVER:

   main() {
       epollset<libsocket::socket> eset_;
       unix_dgram_server  srv("/tmp/srvsock“, SOCK_NONBLOCK)；
       eset_.add_fd(srv, LIBSOCKET_READ);  
       eset_.wait(-1);
       ...
   }
   

   CLIENT

   main() {
       libsocket::unix_dgram_client cl("/tmp/clsock");
       cl.sndto(msg, msg_len, "/tmp/clsock");
       ...
   }
   

   The server would never get the msg's data, because the client unlink the path "/tmp/clsock" in client's constructor.
5. dermesser commented on Oct 17, 2019

   

   dermesser

   on Oct 17, 2019

   Owner

   More actions

   main() {
   libsocket::unix_dgram_client cl("/tmp/clsock");
   cl.sndto(msg, msg_len, "/tmp/clsock");
   ...
   }

   But shouldn't you send it to the server? i.e. /tmp/srvsock? http://dermesser.github.io/libsocket/doc/doxygen/html/classlibsocket_1_1unix__dgram.html#a84c3e94edd3a3db9a156b59e38cb4643

   The client only unlinks /tmp/clsock to bind to it right after (which would otherwise fail).
6. ancloud-teach commented on Oct 23, 2019

   

   ancloud-teach

   on Oct 23, 2019

   Author

   More actions

   I am so sorry. I write the wrong code for CLIENT.

   for example,
   SERVER:

   main() {
   epollsetlibsocket::socket eset_;
   unix_dgram_server srv("/tmp/srvsock“, SOCK_NONBLOCK)；
   eset_.add_fd(srv, LIBSOCKET_READ);
   eset_.wait(-1);
   ...
   }
   CLIENT

   main() {
   libsocket::unix_dgram_client cl("/tmp/srvsock");
   cl.sndto(msg, msg_len, "/tmp/srvsock");
   ...
   }

   The server would never get the msg's data, because the client unlink the path "/tmp/srvsock" in client's constructor.
7. dermesser commented on Nov 14, 2019

   

   dermesser

   on Nov 14, 2019

   Owner

   More actions

   Yes, that is intended behavior, because the path in the client constructor is the path the client socket should bind to. Obviously it should bind to its own path, not the server's.