O que é um ciclo de vida típico de um soquete de datagrama do Unix?

Question

Isso é estritamente no contexto do Unix Datagram Sockets: family = AF_UNIX / AF_LOCAL type = SOCK_DGRAM

O seguinte parece correto para um cenário em que um cliente envia uma mensagem ao servidor? Envio de servidor ao cliente não exigido a partir de agora.

1. Listening / Soquete do servidor:

   1.1. Criar soquete usando socket()

   1.2. bind() para um caminho de arquivo

   1.3. recv() ou recvfrom() ou recvmsg() ou read() , que será bloqueado por padrão, a menos que seja especificado por fcntl() .

2. Soquete do cliente:

   2.1. Criar soquete usando socket()

   2.2. bind() para o caminho do arquivo em 1.2. Isto mostra EADDRINUSE que o endereço já está em uso. Se connect() for usado, então resultará em operação EPERM não permitida.

   2.3. sendto() ou sendmsg() ou write()

Answer 1

Sua lógica de soquete de escuta / servidor parece correta, mas para o soquete do cliente:

bind() to the file path in 1.2. This throws EADDRINUSE that address already in use.

... naturalmente, porque o soquete de escuta já reivindicou esse endereço.

O soquete do cliente normalmente deseja connect() para o caminho no qual o soquete de escuta está escutando.

If connect() is used instead then it results in EPERM operation not permitted.

Não sei por que você receberia esse erro. Eu estava pensando em um problema de permissão, mas problemas de permissão parecem resultar em EACCES, não em EPERM. Tente sem usar connect() ? Se você omitir connect() para soquetes de datagrama, isso significa que você precisa usar sendto() para especificar o endereço de destino para cada pacote. Você não pode usar send() ou write() , que espera que o endereço de destino tenha sido pré-selecionado usando connect() .