|
ahuahuauhahuauhuahh lo sapevoooooooooo la microsoft non è stupida!!!!!! lo sapevo che aveva qualcosa in serbo per i suoi vecchi errori!!!!!
leggi qui!!!
Jason Clark
MSDN Magazine July 2003
...
Read more!
Rete
Connettiti con .NET Framework 3.5
Mariya Atanasova and Larry Cleeton and Mike Flasko and Amit Paka
In questo articolo verranno discussi i seguenti argomenti:
* Prestazioni della classe Socket
* URL internazionalizzati
* Spazio dei nomi System.Net.PeerToPeer
In questo articolo verranno utilizzate le seguenti tecnologie:
.NET Framework
Sommario
Prestazioni della classe Socket
Supporto degli IRI (International Resource Identifier)
Spazio dei nomi System.Net.PeerToPeer
Conclusioni
In Microsoft ® .NET Framework lo spazio dei nomi System.Net espone le funzionalità di molti protocolli di rete, quali HTTP e SMTP. La nuova versione 3.5 di .NET Framework (che verrà fornita con Visual Studio® 2008, precedentemente noto con il nome in codice di "Orcas") contiene numerosi miglioramenti funzionali e prestazionali per questi importanti livelli di rete. In quest'articolo verranno prese in esame tre modifiche principali apportate dal team System.Net:
* L'API Socket ad alte prestazioni
* Il supporto degli IRI (International Resource Identifier) per gli URI (Uniform Resource Identifier)
* Lo spazio dei nomi peer-to-peer (P2P)
Con la nuova versione 3.5 di .NET Framework verranno introdotte modifiche al framework stesso. Le funzionalità descritte in questo articolo sono disponibili nella versione Beta 1 di Visual Studio 2008, scaricabile da MSDN®.
Prestazioni della classe Socket
Nella versione 2.0 di .NET Framework, lo spazio dei nomi System.Net.Sockets fornisce una classe Socket che offre pressoché tutte le funzionalità delle API Win32® di Windows®. Queste funzionalità vengono messe a disposizione tramite una classe con metodi e proprietà progettate per gli sviluppatori di codice gestito. In Socket è inclusa un serie di metodi sincroni, fra cui Send e Receive, con l'aggiunta di numerosi parametri utilizzabili in varie situazioni. Questi metodi sincroni sono facili da utilizzare e sono particolarmente adatti a semplici attività di rete che prevedono l'utilizzo di socket. In Socket è inoltre disponibile una serie di metodi asincroni basati sul modello di programmazione asincrono (Asynchronous Programming Model, APM) prevalente in tutto .NET Framework (per ulteriori informazioni, vedere msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs). Questi metodi asincroni semplificano relativamente l'utilizzo asincrono della classe Socket e consentono di gestire un numero elevato di socket o molte operazioni di invio e ricezione su un numero elevato di socket.
La classe Socket inclusa nella versione 2.0 è adatta a un'ampia gamma di applicazioni client aventi la necessità di utilizzare socket di rete, oltre che per alcune applicazioni server e di servizio. Purtroppo in alcuni scenari di applicazioni di servizio non è possibile utilizzare la classe Socket inclusa nella versione 2.0. È comunque possibile ovviare a questi casi ricorrendo ai linguaggi nativi che utilizzano direttamente le API WinSock di Windows. Il problema principale della classe Socket della versione 2.0 è costituito dall'utilizzo di un numero eccessivo di cicli della CPU per eseguire una singola operazione di I/O su socket e quando vengono allocati gli oggetti sottostanti necessari per mantenere le operazioni di I/O su un gran numero di socket contemporaneamente.
Utilizzando Common Language Runtime (CLR) incluso in .NET Framework 3.5 è ora possibile gestire contemporaneamente un elevato numero di oggetti Overlapped in maniera più efficiente. Gli oggetti Overlapped in CLR eseguono efficacemente il wrapping della struttura OVERLAPPED nativa di Windows utilizzata per gestire le operazioni di I/O asincrone. Esiste una istanza dell'oggetto Overlapped per ogni operazione di I/O asincrona di Socket in corso. Inoltre è ora possibile disporre di oltre 60.000 socket connessi, mantenendo nel contempo un'operazione di I/O di ricezione asincrona in attesa su ogni socket.
La classe Socket inclusa nella versione 2.0 utilizza le porte di completamento di I/O di Windows per il completamento di operazioni di I/O asincrone. Ciò consente alle applicazioni di essere facilmente scalabili su un gran numero di socket aperti. Con .NET Framework viene implementata la classe System.Threading.ThreadPool, la quale fornisce i thread di completamento che leggono le porte di completamento e completano le operazioni di I/O asincrone. Durante lo sviluppo della nuova versione 3.5 di .NET Framework, ci siamo impegnati a fondo per eliminare l'overhead nei percorsi di codice fra la lettura di una porta di completamento e la chiamata al delegato di completamento di un'applicazione o la segnalazione dell'oggetto evento di completamento dell'I/O in un oggetto IAsyncResult.
Il modello APM di .NET Framework è definito anche modello Begin/End perché, per iniziare un'operazione asincrona, viene chiamato un metodo Begin e viene restituito un oggetto IAsyncResult. Se lo si desidera, è possibile fornire come parametro al metodo Begin un delegato, che verrà chiamato una volta completata l'operazione asincrona, altrimenti un thread può restare in attesa su IAsyncResult.AsyncWaitHandle. Quando viene eseguita la richiamata o viene segnalata l'attesa, viene chiamato il metodo End per ottenere i risultati dell'operazione asincrona. Questo modello è flessibile, relativamente semplice da utilizzare e comune in tutto .NET Framework.
È importante osservare, tuttavia, che esiste un prezzo da pagare nel caso si esegua un numero significativo di operazioni di socket asincrone. È necessario creare un oggetto IAsyncResult per ogni operazione e gli oggetti non possono essere riutilizzati. Ciò può influire pesantemente sulle prestazioni, sovraccaricando l'allocazione degli oggetti e la garbage collection. Come soluzione alternativa per questo problema, nella nuova versione è incluso un modello di metodi per eseguire l'I/O asincrono con i socket. Questo nuovo modello non richiede l'allocazione di un oggetto di contesto dell'operazione per ogni operazione socket.
Anziché creare un modello interamente nuovo, ne abbiamo utilizzato uno esistente, apportandogli una modifica fondamentale. Nella classe Socket sono ora disponibili metodi che utilizzano una variante del modello di completamento basato sugli eventi. Per iniziare un invio asincrono su un socket, nella versione 2.0 si utilizzerebbe il codice seguente:
void OnSendCompletion(IAsyncResult ar) { }
IAsyncResult ar = socket.BeginSend(buffer, 0, buffer.Length,
SocketFlags.None, OnSendCompletion, state);
Sempre nella nuova versione, è possibile, in alternativa, procedere come descritto di seguito:
void OnSendCompletion(object src, SocketAsyncEventArgs sae) { }
SocketAsyncEventArgs sae = new SocketAsyncEventArgs();
sae.Completed += OnSendCompletion;
sae.SetBuffer(buffer, 0, buffer.Length);
socket.SendAsync(sae);
Qui vi sono alcune differenze sensibili. L'oggetto che esegue il wrapping del contesto dell'operazione è un oggetto SocketAsyncEventArgs anziché IAsyncResult. L'applicazione crea e gestisce (e può addirittura riutilizzare) oggetti SocketAsyncEventArgs. Tutti i parametri per l'operazione socket sono specificati dalle proprietà e dai metodi dell'oggetto SocketAsyncEventArgs e anche lo stato di completamento è fornito dalle proprietà dell'oggetto SocketAsyncEventArgs, infine è necessario l'utilizzo di un metodo di completamento per la richiamata del gestore eventi.
Tutte queste modifiche hanno come effetto un notevole miglioramento delle prestazioni e della scalabilità della classe System.Net.Sockets di .NET Framework 3.5. Due di questi miglioramenti saranno conseguiti automaticamente dalle applicazioni esistenti, mentre il terzo, ovvero i nuovi metodi Socket, potrà essere utilizzato soltanto modificando un'applicazione, sebbene questi metodi forniscano maggiore scalabilità per le applicazioni basate su socket più complesse.
riassuntino...
beginsend fa schifo quindi hanno implementato il sendsyn che usa gli eventi invece di creare l'oggetto asynresult auhauhah ecco perche sale di ram sto cretinoooo!!!
| ![C# / VB.NET - [VB.NET] TROVATO FINALMENTE AUHHUAAHU](/data/logos/logositov8_easter.png)
comunque la soluzione potrebbe essere questa (ho creato un nuovo modulo perchè mi stavo incasinando 
):
