You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To be able to immediately notify a client that something changed, we
85
-
need a ((connection)) to that client. Since web browsers do not
86
-
traditionally accept connections and clients are often behind
87
-
((router))s that would block such connections anyway, having the
88
-
server initiate this connection is not practical.
84
+
Para ser capaces de notificar inmediatamente a un cliente que algo ha cambiado, necesitamos una ((conexión)) con ese cliente. Como los navegadores normalmente no aceptan conexiones y los clientes están detrás
85
+
de ((router))s que bloquearían la conexión de todas maneras, hacer que el
86
+
servidor inicie la conexión no es práctico.
89
87
90
-
We can arrange for the client to open the connection and keep it
91
-
around so that the server can use it to send information when it needs
92
-
to do so.
88
+
Podemos hacer que el cliente abra la conexión y la mantenga de tal manera que
89
+
el servidor pueda usarla para mandar información cunado lo necesite.
93
90
94
91
{{index socket}}
95
92
96
-
But an ((HTTP)) request allows only a simple flow of information: the
97
-
client sends a request, the server comes back with a single response,
98
-
and that is it. There is a technology called _((WebSockets))_,
99
-
supported by modern browsers, that makes it possible to open
100
-
((connection))s for arbitrary data exchange. But using them properly
101
-
is somewhat tricky.
102
-
103
-
In this chapter, we use a simpler technique—((long polling))—where
104
-
clients continuously ask the server for new information using regular
105
-
HTTP requests, and the server stalls its answer when it has nothing
106
-
new to report.
107
-
108
-
{{index "live view"}}
109
-
110
-
As long as the client makes sure it constantly has a polling request
111
-
open, it will receive information from the server quickly after it
112
-
becomes available. For example, if Fatma has our skill-sharing
113
-
application open in her browser, that browser will have made a request
114
-
for updates and will be waiting for a response to that request. When Iman
115
-
submits a talk on Extreme Downhill Unicycling, the server will notice
116
-
that Fatma is waiting for updates and send a response containing the
117
-
new talk to her pending request. Fatma's browser will receive the data
118
-
and update the screen to show the talk.
119
-
120
-
{{index robustness, timeout}}
121
-
122
-
To prevent connections from timing out (being aborted because of a
123
-
lack of activity), ((long polling)) techniques usually set a maximum
124
-
time for each request, after which the server will respond anyway,
125
-
even though it has nothing to report, after which the client will
126
-
start a new request. Periodically restarting the request also makes
127
-
the technique more robust, allowing clients to recover from temporary
128
-
((connection)) failures or server problems.
93
+
Pero una petición ((HTTP)) permite sólamente un flujo simple de información:
94
+
el cliente manda una petición, el servidor responde con una sola respuesta,
95
+
y eso es todo. Existe una tecnología moderna llamada _((WebSockets))_,
96
+
soportada por los principales navegadores, que hace posible abrir
97
+
((conexiones)) para intercambio arbitrario de datos. Pero usarla
98
+
correctamente es un poco complicado.
99
+
100
+
En este capítulo usamos una técnica más simple, el _long polling_ en donde los
101
+
clientes continuamente le piden al servidor nueva información usando
102
+
las peticiones HTTP regulares, y el server detiene su respuesta cuando no
103
+
hay nada nuevo que reportar.
104
+
105
+
{{index "vista en vivo"}}
106
+
107
+
Mientras el cliente se asegure de tener constantemente abierta una
108
+
petición de sondeo, recibirá nueva información del servidor
109
+
muy poco tiempo después de que esté disponible. Por ejemplo, si
110
+
Fatma tiene nuestra aplicación abierta in su navegador, ese navegador
111
+
ya habrá hecho una petición de actualizaciones y estará esperando por
112
+
una respuesta a esa petición. Cuando Iman manda una charla acerca de
113
+
Bajada Extrema en Monociclo, el servidor se dará cuenta de que
114
+
Fatma está esperando actualizaciones y mandará una respuesta
115
+
conteniendo la nueva charla, respondiendo a la petición pendiente. El
116
+
navegador de Fatma recibirá los datos y actualizará la pantalla.
117
+
118
+
{{index robustez, vencimiento}}
119
+
120
+
Para evitar que las conexiones se venzan (que sean abortadas por falta
121
+
de actividad), las técnicas de _((long polling))_ usualmente ponen el
122
+
tiempo máximo para cada petición después de lo cuál el servidor
123
+
responderá de todos modos aunque no tenga nada que reportar, después
124
+
de lo cuál el cliente iniciará otra petición. Reiniciar periódicamente
125
+
la petición hace además la técnica más robusta, permitiendo a los clientes
126
+
recuperarse de fallas temporales en la ((conexión)) o problemas del servidor.
127
+
129
128
130
129
{{index "Node.js"}}
131
130
132
-
A busy server that is using long polling may have thousands of waiting
133
-
requests, and thus ((TCP)) connections, open. Node, which makes it
134
-
easy to manage many connections without creating a separate thread of
135
-
control for each one, is a good fit for such a system.
131
+
Un servidor ocupado que esté usando _long polling_ podría tener miles de
132
+
peticiones esperando, y por lo tanto miles de conexiones ((TCP)) abiertas.
133
+
Node, que hace fácil de manejar muchas conexiones sin crear un hilo de control
134
+
para cada una, es un buen elemento para nuestro sistema.
0 commit comments