Até onde sei, a resposta para essa pergunta é "sim", mas eu queria verificar meu entendimento e, quem sabe, obter uma compreensão mais detalhada e aprofundada.
As chamadas para sendcorrespondem 1:1 com as chamadas para recv?
Para expressar isso de outra forma, se um programa fizer uma chamada sendpara enviar alguns dados por meio de um soquete de rede para outro programa conectado à rede, haverá exatamente 1 e somente 1 chamada feita recvno lado receptor da conexão? (Supondo que o recvbuffer seja grande o suficiente.)
Estou ciente de que os sistemas operacionais e outros hardwares de rede podem fragmentar um pacote IP. No entanto, meu entendimento é que o sistema operacional no lado receptor irá recombinar os pacotes fragmentados antes de apresentar o pacote recombinado a um aplicativo cliente via recv.
O motivo da pergunta é que estou tentando descobrir se, em algumas circunstâncias, preciso fazer recvvárias chamadas para obter todos os dados enviados por uma chamada sendem outra máquina.
A razão óbvia pela qual isso pode ser necessário é porque sendenvia mais dados do que cabe no buffer usado por recv. No entanto, para os propósitos desta questão, vamos supor que a maior quantidade de dados enviados por sendcaberá dentro do buffer usado por recv.
A resposta é principalmente sim para sockets de datagrama como UDP e não para sockets de fluxo como TCP. Presumir erroneamente que uma relação 1:1 entre send e recv também existe com TCP é um erro de programação muito comum. Um erro semelhante com sockets de fluxo é a suposição de que send enviará tudo (verifique o valor de retorno quanto foi realmente enviado) e que recv tentará ler todo o tamanho fornecido (verifique o valor de retorno quanto foi realmente lido).
E mesmo para sockets de datagrama a resposta nem sempre é sim. Ao contrário do TCP, um socket UDP não é confiável e, portanto, datagramas podem ser perdidos (apenas datagramas completos, não partes). Isso significa que pode haver um envio sem recepção correspondente, pois o pacote foi perdido.