communication bidirectionnelle entre les serveurs Web et les navigateurs est rien de nouveau. Stack Overflow le fait aujourd'hui si une nouvelle réponse est postée à une question que vous lisez. Il y a quelques stratégies différentes pour la mise en œuvre des comportements de type socket en utilisant les technologies existantes:
- AJAX court sondage: Se connecter au serveur et lui demander s'il y a des nouveaux messages. Si ce n'est pas le cas, déconnectez-vous immédiatement et recommencez après un court intervalle. Ceci est utile lorsque vous ne voulez pas laisser beaucoup de connexions inactives de longue durée ouvertes sur le serveur, mais cela signifie que vous ne recevrez que les nouveaux messages aussi rapidement que votre intervalle d'interrogation, et vous encourrez le surcoût d'établir un nouvelle connexion HTTP chaque fois que vous interrogez.
- AJAX longue interrogation: Connectez-vous au serveur et laissez la connexion ouverte jusqu'à ce qu'un nouveau message soit disponible. Cela vous permet une livraison rapide de nouveaux messages et des connexions HTTP moins fréquentes, mais il en résulte des processus d'inactivité plus longs sur le serveur.
- Iframe longue interrogation: Identique à ci-dessus, uniquement avec un iframe caché au lieu d'un objet XHR. Utile pour contourner la règle d'origine identique lorsque vous souhaitez effectuer une interrogation longue intersite.
- Plugins: le XMLSocket de Flash, des applets Java, etc. peuvent être utilisées pour établir quelque chose de plus proche d'un vrai bas niveau socket persistante à un navigateur.
Les sockets HTML5 ne modifient pas vraiment les stratégies sous-jacentes disponibles. La plupart du temps, ils ne font que formaliser les stratégies déjà utilisées et permettent d'identifier explicitement les connexions persistantes et de les traiter de manière plus intelligente. Imaginons que vous souhaitiez utiliser la messagerie instantanée Web dans un navigateur mobile. Avec une interrogation longue normale, l'appareil mobile doit rester éveillé pour maintenir la connexion. Avec WebSockets, lorsque l'appareil mobile veut se mettre en veille, il peut transmettre la connexion à un proxy, et lorsque le proxy reçoit de nouvelles données, il peut réveiller l'appareil et renvoyer le message.
Le côté serveur est grand ouvert. Pour implémenter le côté serveur d'une application d'interrogation courte, vous avez juste besoin d'une sorte de file d'attente de messages chronologique. Lorsque les clients se connectent, ils peuvent décaler les nouveaux messages de la file d'attente ou transmettre un décalage et lire les messages plus récents que leur décalage.
long côté serveur La mise en œuvre est l'interrogation où commencer à affiner votre choix. La plupart des serveurs HTTP sont conçus pour des demandes de courte durée: se connecter, demander une ressource, puis se déconnecter. Si 300 personnes visitent votre site en 10 minutes et que chacune prend 2 secondes pour se connecter et télécharger des ressources HTTP, votre serveur aura en moyenne 1 connexion HTTP ouverte à tout moment. Avec une longue application de sondage, vous maintenez soudainement 300 fois plus de connexions.Si vous utilisez votre propre serveur dédié, vous pourrez peut-être gérer cela, mais sur les plates-formes d'hébergement partagées, vous risquez de vous heurter aux limites de ressources, et App Engine ne fait pas exception à la règle. App Engine est conçu pour gérer un volume élevé de demandes à faible latence, par ex. court sondage. Vous pouvez implémenter une interrogation longue sur App Engine, mais ce n'est pas conseillé. les demandes qui durent plus de 30 secondes seront terminées, et les processus longs entraîneront une perte de quota de votre processeur.
La solution d'App Engine pour cela est l'API Channel à venir. L'API de canal implémente une longue interrogation à l'aide de l'infrastructure XMPP robuste de Google.
Brett Bavar and Moishe Lettvin's Google I/O talk expose le modèle d'utilisation comme suit:
App App Engine créer un canal sur un serveur distant, et sont renvoyés un ID de canal qu'ils passent au browser web.
class MainPage(webapp.RequestHandler):
def get(self):
id = channel.create_channel(key)
self.response.out.write(
{'channel_id': id})
Le navigateur Web transmet le canal ID au même serveur distant pour établir une connexion par vote à long iframe:
<script src='/_ah/channel/jsapi'></script>
<script>
var channelID = '{{ channel_id }}';
var channel =
new goog.appengine.Channel(channelId);
var socket = channel.open();
socket.onmessage = function(evt) {
alert(evt.data);
}
</script>
Quand quelque chose se produit intéressant, l'application App Engine peut pousser un message à la le canal de l'utilisateur, et la longue demande de sondage du navigateur le recevra immédiatement:
class OtherPage(webapp.RequestHandler):
def get(self):
# something happened
channel.send_message(key, 'bar')