To nie jest kolejny TcpClient vs Socket.

TcpClient to opakowanie otaczające klasę Socket, które ułatwia rozwój, a także ujawnia podstawowe gniazdo.

nadal ...

Na stronie biblioteki MSDN dla klasy TcpClient można przeczytać następującą uwagę:

Klasa TcpClient zapewnia proste metody łączenia, wysyłania i odbierania danych strumieniowych przez sieć w trybie synchronicznego blokowania.

A dla klasy Socket:

Klasa Socket umożliwia zarówno synchroniczne, jak i asynchroniczne przesyłanie danych przy użyciu dowolnego protokołu komunikacyjnego wymienionego w wyliczeniu ProtocolType.

Aby wysyłać / odbierać niektóre dane asynchronicznie tylko przez TcpCient, należy wykonać wywołanie GetStream, aby pobrać bazowy NetworkStream z / na którym dane mogą być odczytywane / zapisywane asynchronicznie przez wywołanie na nim metod ReadAsync i WriteAsync, zgodnie ze wzorem TAP (potencjalnie używając async / await constructs).

Aby wysyłać / odbierać niektóre dane asynchronicznie przez Socket (nie jestem ekspertem, ale myślę, że mam rację), możemy bezpośrednio odczytywać / zapisywać z / na instancji gniazda, wywołując BeginRead / EndRead BeginWrite / EndWrite (lub po prostu ReadAsync lub WriteAsync .. nie ujawniający wzorca TAP - tj. Nie zwracający zadania .. mylący).

Po pierwsze, jakikolwiek pomysł, dlaczego klasa Socket w .NET 4.5 nie implementuje w żaden sposób wzorca TAP, tj. Zwracającego zadanie ReadAsync i WriteAsync (zdarzenie, jeśli zostało inaczej wywołane, aby zachować kompatybilność wsteczną)?

W każdym razie, dość łatwo zbudować metodę Task z pary metod modelu APM, powiedzmy więc, że nazywam tę metodę asynchroniczną (do odczytu) ReadAsyncTAP (zwracając zadanie).

Dobrze ? Więc powiedzmy, że chcę kodować metodę klientaasync Task<Byte[]> ReadNbBytes(int nbBytes) że zadzwonię z mojego kodu, aby asynchronicznie odczytać pewną liczbę bajtów z sieci.

Implementacja tej metody opartej wyłącznie na TcpClient spowodowałaby otrzymanie NetworkStream wywołując GetStream i zawierał asynchroniczną pętlę oczekującą na wywołania ReadAsync aż do zapełnienia bufora.

Implementacja tej metody opartej na Socket będzie zawierała pętlę asynchroniczną oczekującą na ReadAsyncTAP do momentu zapełnienia bufora.

Pod koniec dnia, z punktu widzenia kodu klienta, przypuszczam, że to nie ma znaczenia. W obu przypadkach wezwanie doawait ReadNbBytes natychmiast „wróci”. Jednak przypuszczam, że to robi różnicę za kulisami ... Czy dla TcpClient, polegającego na NetworkStream, czy odczyt w jakiś sposób blokuje lub nie, w porównaniu z bezpośrednim użyciem gniazda? Jeśli nie, czy uwagi dotyczące TcpClient są błędne, jeśli chodzi o tryb synchronicznego blokowania?

Byłoby bardzo zafascynowane, gdyby ktoś mógł wyjaśnić!

Dzięki.