Les appels de serveurs Web asynchrones dans Silverlight et les connexions HTTP maximales

Question

J'ai lu que Silverlight 2.0 impose par conception un modèle asynchrone lors de la communication avec le serveur Web. Je n'ai pas eu l'occasion d'expérimenter avec Silverlight, mais je suppose qu'il utilise un pool de threads pour gérer les threads comme dans le .NET Framework.

Maintenant, puisque certains navigateurs, notamment Internet Explorer, ont une limite codée en dur d'au maximum deux connexions HTTP simultanées qui peuvent être faites sur le serveur web, que se passe-t-il si je fais un tas de demandes asynchrones de Silverlight?

Est-ce que Silverlight contourne cette limitation dans le navigateur Web et ouvre autant de connexions HTTP que de threads disponibles, ou les demandes asynchrones s'alignent-elles et attendent-elles qu'une des deux connexions soit disponible?

Answer 1

Dans IE (n'en ai pas testé d'autres) Silverlight est limité à 2 connexions à la fois.

Le comportement dans Silverlight consiste simplement à ne pas effectuer la demande. Ainsi, si vous effectuez 5 demandes de service Web Async à la suite, les deux premières se produiront, les trois autres ne le seront pas. Aucune exception est levée que je l'ai vu ...

Fiddler est une grande aide ici :)

Answer 2

Je suppose, étant une application .NET Silverlight 2 a une limite de navigateur indépendante.
Je suppose Il est maxconnection attribut dans Machine.config comme mentionné dans http://support.microsoft.com/kb/828219

Answer 3

Tout d'abord le fichier Machine.config ne serait pas utilisé comme le contrôle Silverlight est sandbox avec sa propre version du CoreCLR.

Je crois que le contrôle Silverlight utilise réellement le navigateur sous-jacent pour effectuer les requêtes HTTP asynchrones. Cela est probablement le cas lorsque le contrôle Silverlight ne peut pas accéder aux informations de défaillance SOAP car la spécification SOAP exige que le serveur renvoie un code de réponse HTTP 500 et que le contrôle Silverlight ne l'obtienne pas du navigateur hébergeant le contrôle.

Cet article here sert à confirmer cela. En ce qui concerne la limite des connexions HTTP simultanées, je crois que IE5 et plus tard limiter le nombre de connexions au même site basé sur la version du protocole HTTP - HTTP/1.0 il limite à 4 connexions et HTTP/1.1 à 3 connexions. La plupart du temps, le serveur web limitera le nombre de connexions à 2 par client, en mettant en file d'attente ou en supprimant le reste.

Answer 4

Firefox est également limité à deux connexions, en plus de IE comme l'a déjà dit.

Notez que la limite est par nom d'hôte.

Si vous ajoutez des entrées à votre fichier hosts ou si vous utilisez des alias DNS, vous pouvez obtenir plus de connexions. Par exemple, lors des tests, ajoutez des lignes comme '127.0.0.1 test1' à votre fichier hosts, puis vous pouvez ouvrir deux connexions à http://localhost et deux autres à http://test1

Answer 5

Créez une interface de gestionnaire de messagerie pour votre client. Toute requête sortante est enregistrée dans une file d'attente traitée par ce gestionnaire. Il traite en série les messages mis en file d'attente (c'est-à-dire, lorsque le rappel du dernier message envoyé au serveur est appelé, peut ensuite procéder en toute sécurité au traitement du prochain message mis en file d'attente).

Vous pouvez consommer l'autre ressource de connexion en conservant une connexion Comet ouverte au serveur. Le serveur enverra tous les messages de retour au client via cette connexion Comet. Vous devrez écraser les messages sortants avec un numéro unique qui peut être incorporé en tant que propriété sur les messages entrants - afin que les résultats puissent être corrélés à la demande. Le gestionnaire de messagerie envoie un message de résultat au gestionnaire approprié pour ce résultat. Essentiellement, vous finissez par utiliser deux ressources de connexion pour établir une messagerie bidirectionnelle. Mais il n'y a aucune limite artificielle sur le nombre de demandeurs sur le client (bien que la demande sera transmise en série au serveur). Cependant, l'envoi est toujours rapide, car vous n'attendez pas qu'un résultat soit calculé. Vous devez simplement envoyer le message de manière fiable au serveur et le renvoyer. Les résultats reviennent de manière asynchrone sur l'autre connexion Comet.

nous faisons quelque chose le long de ces lignes avec nos applications client Flex conjointement à Adobe BlazeDS en cours d'exécution dans notre serveur web Tomcat:

A Flex-based asynchronous stack