Este não é mais um TcpClient vs Socket.

TcpClient é um wrapper em torno da classe Socket para facilitar o desenvolvimento, também expondo o Socket subjacente.

ainda ...

Na página da biblioteca MSDN para a classe TcpClient, pode-se ler a seguinte observação:

A classe TcpClient fornece métodos simples para conectar, enviar e receber dados de fluxo em uma rede no modo de bloqueio síncrono.

E para a classe Socket:

A classe Socket permite que você execute transferência de dados síncrona e assíncrona usando qualquer um dos protocolos de comunicação listados na enumeração ProtocolType.

Para enviar / receber alguns dados de forma assíncrona somente por meio do TcpCient, uma chamada para GetStream deve ser feita para recuperar o NetworkStream subjacente de / no qual os dados podem ser lidos / gravados de forma assíncrona chamando os métodos ReadAsync e WriteAsync, seguindo o padrão TAP (potencialmente usando construções async / await).

Para enviar / receber alguns dados de forma assíncrona via Socket (não sou especialista, mas acho que acertei), podemos ler / escrever diretamente de / na instância do soquete chamando BeginRead / EndRead BeginWrite / EndWrite (ou apenas ReadAsync ou WriteAsync .. não expondo o padrão TAP - ou seja, não retornando uma tarefa .. confuso).

Primeiro de tudo, alguma idéia por que a classe Socket no .NET 4.5 não implementa de qualquer forma o padrão TAP, ou seja, ReadAsync e WriteAsync retornando Task (evento se chamado de forma diferente para preservar compatibilidade com versões anteriores)?

De qualquer forma, fácil o suficiente para construir um método Task a partir do par de métodos modelo APM, então vamos dizer que eu chamo este método assíncrono (para leitura) ReadAsyncTAP (retornando uma tarefa).

OK ? Então agora vamos dizer que eu quero codificar um método clienteasync Task<Byte[]> ReadNbBytes(int nbBytes) que eu chamarei do meu código para ler de forma assíncrona um certo número de bytes da rede.

A implementação desse método baseada exclusivamente em um TcpClient obteria o NetworkStream chamando GetStream e conteria um loop assíncrono aguardando em chamadas ReadAsync até o buffer ficar cheio.

A implementação desse método com base no Socket conteria um loop assíncrono aguardando no ReadAsyncTAP até o buffer ficar cheio.

No final do dia, do ponto de vista do código do cliente, suponho que não faz diferença. Em ambos os casos, a chamada paraawait ReadNbBytes irá "retornar" imediatamente. No entanto, suponho que faça diferença nos bastidores ... Para o TcpClient, contando com o NetworkStream, a leitura de alguma forma bloqueia ou não a qualquer momento, comparado ao uso direto do socket? Se não, a observação feita para o TcpClient está errada ao falar sobre o modo de bloqueio síncrono?

Seria muito apprecited Se alguém pudesse esclarecer!

Obrigado.