2013-08-24 14 views
12

Gibt es Pläne des .NET-Teams, die in Windows 8/Server 2012 eingeführten RIO-Sockets in .NET verfügbar zu machen?RIO-Sockets (registrierte E/A) in .NET

Was sind meine Optionen in der Zwischenzeit, um sie aus .NET zu verwenden - erweitern Sie die Socket-Klasse?

Abgesehen von der Windows-API-Dokumentation, What's New for Windows Sockets, und einem Channel9-Video, New Techniques to Develop Low-Latency Network Apps, kann ich kaum weitere Dokumentation über sie finden.

+1

Sie könnten wahrscheinlich [diese Serie auf RIO überprüfen und sie zu P/Invoke für Vorspeisen übersetzen] (http://www.serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-example-) udp-servers.html). – user7116

Antwort

5

Ich habe eine Menge über meine anfänglichen Ermittlungen in RIO geschrieben aus dem nativen Code here (wie der Kommentator auf Ihre ursprüngliche Frage hingewiesen).

Ich würde gerne wissen, was Sie mit RIO aus verwaltetem Code erreichen möchten? RIOs wahrscheinlichste Zielgruppe sind Entwickler, die Latenz in ihrem Netzwerkcode reduzieren müssen. Persönlich bin ich nicht davon überzeugt, dass verwalteter Code für die Art von Anwendungen, auf die RIO abzielte, ideal ist; Ich könnte falsch liegen, aber ich würde erwarten, dass die Chance, dass die CLR jederzeit eine Müllsammlung auslösen könnte, nicht die Art von Sache wäre, die jemand mit RIO möchte ...

Wie auch immer. Ich denke, wenn Sie RIO von verwaltetem Code verwenden möchten, dann würde ich empfehlen, P/Invoke einfach NICHT zu verwenden und stattdessen eine Komponente zu schreiben, die alle RIO-Arbeiten in nativem Code verwaltet und die möglicherweise in verschiedene Netzwerke zurückverwaltet wird Veranstaltungen. Aber nochmal, genau so würde ich es machen ...

+8

Ich arbeite in der Finanzbranche und obwohl ich zustimme, dass wir etwas mehr Leistung beim Schreiben von nativem Code herausholen könnten, waren wir in der Lage, einen Managed Application Stack zu entwickeln, der weitgehend GC-frei, mit geringem Jitter und geringer Latenz ist. Die spezielle Komponente, für die ich RIO for verwenden würde, hat eine durchschnittliche Latenz von 5 usec pro verarbeitetem Paket, aber verursacht einen ~ 20 usec-Treffer pro Aufruf des Benutzers, um den Kernel-Modus zu winsock zu überführen. Wenn wir das über RIO nach unten bringen könnten, wäre das ein sofortiger Gewinn, ohne dass wir die Kernel-Bypass-Route gehen müssten. - Danke für die Links zu Ihren Artikeln! – TJF

+0

Hört sich so an, als ob es sich lohnt, einen Blick darauf zu werfen. –

+1

@TJF Wie hast du deinen Server GC frei gemacht und die Latenz reduziert? – tunafish24

3

RIO wird experimentell für die API "channels" untersucht, derzeit in einer Anfangs-/Explorationsstufe, aber von hier aus verwendbar: https://github.com/davidfowl/Channels. Dies ist neben einer libuv-API und einer "Channels" -basierten Winsock-API. In Bezug auf Ihre Frage zur Erweiterung der Socket-Klasse: Die Art dieser APIs scheint einen anderen Ansatz wünschenswert zu machen - daher "Kanäle".

+0

Es gibt auch ein "RioSharp" -Projekt auf GitHub: https://github.com/aL3891/RioSharp – TJF