Gniazda RIO (zarejestrowane wejścia/wyjścia) w .NET

Czy są jakieś plany zespołu .NET, aby udostępnić gniazda RIO wprowadzone w systemie Windows 8/Server 2012 w .NET?Gniazda RIO (zarejestrowane wejścia/wyjścia) w .NET

Jakie są moje opcje tymczasowe, aby móc je wykorzystać z .NET - rozszerzyć klasę Socket?

Poza dokumentacją interfejsu API Windows, What's New for Windows Sockets i filmem z Channel9, New Techniques to Develop Low-Latency Network Apps, nie mogę znaleźć żadnej dodatkowej dokumentacji na ich temat.

Źródło

2013-08-24 TJF

Prawdopodobnie możesz [sprawdzić tę serię na RIO i przetłumaczyć je na P/Invoke na początek] (http://www.serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-example- udp-servers.html). – user7116

Dużo napisałem o moich wstępnych badaniach RIO z natywnego kodu here (jak zauważył komentujący na twoje pierwotne pytanie).

Chciałbym wiedzieć, co masz nadzieję osiągnąć, używając RIO z kodu zarządzanego? Prawdopodobnie docelowi odbiorcy RIO to programiści, którzy muszą zmniejszyć opóźnienie w kodzie sieciowym. Osobiście nie jestem przekonany, że kod zarządzany jest koniecznie idealny dla aplikacji, do których skierowany był RIO; Mogę się mylić, ale spodziewam się, że szansa, że CLR może wywołać zbieranie śmieci w jakimkolwiek momencie, nie byłaby rzeczą, której ktoś używający RIO chciałby ...

W każdym razie. Myślę, że gdybyś chciał użyć RIO z kodu zarządzanego, to poleciłbym NIE po prostu za pomocą P/Invoke i zamiast tego pisanie komponentu, który zarządza wszystkimi funkcjami RIO w natywnym kodzie i który, być może, wraca do zarządzania w różnych sieciach wydarzenia. Ale znowu, tak po prostu bym to zrobił ...

Źródło

2013-08-24 20:42:17

Pracuję w branży finansowej i choć zgadzam się, że będziemy w stanie wycisnąć nieco więcej wydajności przy pisaniu natywnego kodu, byliśmy w stanie stworzyć zarządzany stos aplikacji, który jest w dużej mierze wolny od GC, z niskim jitterem i niskim opóźnieniem. Konkretny komponent, w którym będę używał RIO, ma średnią zwłokę 5 punktów na każdy przetworzony pakiet, ale dostaje około ~ 20krotnego trafienia na każde połączenie dla użytkownika do przejścia trybu jądra do trybu winsock. Gdybyśmy mogli wprowadzić to za pośrednictwem RIO, które wydawałoby się natychmiastową wygraną bez konieczności przechodzenia na obwodnicę jądra. - Dzięki za linki do twoich artykułów! – TJF

Wygląda na to, że warto w to zaglądać. –

@TJF w jaki sposób uwolniłeś swój serwer od GC i skrócisz również czas oczekiwania? – tunafish24

RIO jest badane eksperymentalnie dla API "kanałów", obecnie w fazie początkowej/eksploracji, ale użyteczne stąd: https://github.com/davidfowl/Channels. Jest to zgodne z API libuv i interfejsem API winsock opartym na "kanałach". W odniesieniu do pytania dotyczącego rozszerzenia klasy socket: wydaje się, że charakter tych interfejsów sprawia, że pożądane jest inne podejście - stąd "kanały".

Źródło

2016-09-02 21:36:00

Istnieje również projekt "RioSharp" na GitHub: https://github.com/aL3891/RioSharp – TJF

Gniazda RIO (zarejestrowane wejścia/wyjścia) w .NET

Odpowiedz

Powiązane problemy