2013-08-24 9 views
12

Esistono piani del team .NET per rendere disponibili i socket RIO introdotti in Windows 8/Server 2012 in .NET?Zoccoli RIO (I/O registrati) in .NET

Quali sono le opzioni nel frattempo per utilizzarle da .NET. Estendere la classe Socket?

Oltre alla documentazione dell'API di Windows, What's New for Windows Sockets e un video Channel9, New Techniques to Develop Low-Latency Network Apps, riesco a malapena a trovare ulteriore documentazione su di essi.

+1

Si potrebbe probabilmente [controllare questa serie su RIO e tradurli in P/Invoke per gli utenti iniziali] (http://www.serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-example- UDP-servers.html). – user7116

risposta

5

Ho scritto molto sulle mie indagini iniziali su RIO dal codice nativo here (come indicato dal commentatore della domanda originale).

Sarei interessato a sapere cosa speri di ottenere utilizzando RIO dal codice gestito? Il pubblico di destinazione probabile di RIO sono gli sviluppatori che hanno bisogno di ridurre la latenza nel loro codice di rete. Personalmente non sono convinto che il codice gestito sia necessariamente l'ideale per il tipo di applicazioni a cui è rivolto RIO; Potrei sbagliarmi, ma mi aspetterei che avere la possibilità che il CLR possa innescare una raccolta rifiuti in qualsiasi momento non sarebbe il tipo di cosa che qualcuno che usa RIO vorrebbe ...

In ogni caso. Penso che se si volesse utilizzare RIO dal codice gestito, allora NON raccomanderei semplicemente di usare P/Invoke e invece di scrivere un componente che gestisce tutto il lavoro RIO nel codice nativo e che, forse, richiama in gestione su varie reti eventi. Ma ancora, è proprio come lo farei io ...

+8

Io lavoro nel settore finanziario e mentre sono d'accordo che saremmo in grado di spremere un po 'più di codice nativo per la performance, siamo stati in grado di sviluppare uno stack di applicazioni gestite che è largamente privo di GC, con jitter basso e bassa latenza. Il particolare componente che utilizzerei RIO ha una latenza media di 5usec per pacchetto elaborato, ma incorre in un hit da ~ 20usec per chiamata all'utente alla transizione in modalità kernel in winsock. Se potessimo ridurlo via RIO sembrerebbe una vincita istantanea senza dover percorrere il percorso di bypass del kernel. - Grazie per i link ai tuoi articoli! – TJF

+0

Sembra che valga la pena esaminare in seguito. –

+1

@TJF come hai reso GC server libero e ridotto la latenza? – tunafish24

3

RIO è stato studiato sperimentalmente per l'API "canali", attualmente in una fase di inizio/esplorazione, ma utilizzabile da qui: https://github.com/davidfowl/Channels. Questo è insieme a un'API libuv e un'API Winsock basata su "canali". Rispetto alla tua domanda sull'estensione della classe socket: la natura di queste API sembra rendere desiderabile un approccio diverso, quindi "canali".

+0

C'è anche un progetto "RioSharp" su GitHub: https://github.com/aL3891/RioSharp – TJF