libsocket::unix_dgram_client would unlink the socket's path

[ancloud-teach]

the unix_dgram_client's constructor, which contain the unix socket path, would unlink the socket path. The path cretate by unix server. The unix path would be no useful for server, after create the unix client.

unix_dgram_client(const char* path, int flags = 0) ==> create_unix_dgram_socket() ==> unlink(bind_path)

[dermesser]

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?

[ancloud-teach]

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;
}

[dermesser]

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.

[ancloud-teach]

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.

[dermesser]

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).

[ancloud-teach]

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.

[dermesser]

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.