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
Copy file name to clipboardExpand all lines: doc/esp8266wifi/client-examples.rst
+66-4
Original file line number
Diff line number
Diff line change
@@ -87,11 +87,11 @@ If connection is successful, we should send request the host to provide specific
87
87
Read Reply from the Server
88
88
~~~~~~~~~~~~~~~~~~~~~~~~~~
89
89
90
-
Then, while connection by our client is still alive (``while (client.connected())``, see below) we can read line by line and print out server's response:
90
+
Then, while connection by our client is still alive or while data are available to read (``while (client.connected() || client.available())``, see below) we can read line by line and print out server's response:
91
91
92
92
.. code:: cpp
93
93
94
-
while (client.connected())
94
+
while (client.connected() || client.available())
95
95
{
96
96
if (client.available())
97
97
{
@@ -102,7 +102,9 @@ Then, while connection by our client is still alive (``while (client.connected()
102
102
103
103
The inner ``if (client.available())`` is checking if there are any data available from the server. If so, then they are printed out.
104
104
105
-
Once server sends all requested data it will disconnect and program will exit the ``while`` loop.
105
+
Data can be unavailable while the TCP connection is still alive. That means data could be later received.
106
+
107
+
Once server sends all requested data it will disconnect, then once all received data are read, program will exit the ``while`` loop.
106
108
107
109
Now to the Sketch
108
110
~~~~~~~~~~~~~~~~~
@@ -152,7 +154,7 @@ Complete sketch, including a case when contention to the server fails, is presen
152
154
);
153
155
154
156
Serial.println("[Response:]");
155
-
while (client.connected())
157
+
while (client.connected() || client.available())
156
158
{
157
159
if (client.available())
158
160
{
@@ -246,6 +248,66 @@ In case server's web address is incorrect, or server is not accessible, you shou
246
248
247
249
[Connecting to www.wrong-example.com ... connection failed!]
248
250
251
+
252
+
General client loop
253
+
~~~~~~~~~~~~~~~~~~~
254
+
255
+
Here is a general TCP sending / receiving loop:
256
+
257
+
.. code:: cpp
258
+
259
+
while (client.available() || client.connected())
260
+
{
261
+
if (client.available())
262
+
{
263
+
// client.available() bytes are immediately available for reading
264
+
// warning: reading them *allows* peer to send more, so they should
265
+
// be read *only* when they can immediately be processed, see below
266
+
// for flow control
267
+
}
268
+
if (client.connected())
269
+
{
270
+
if (client.availableForWrite() >= N)
271
+
{
272
+
// TCP layer will be able to *bufferize* our N bytes,
273
+
// and send them *asynchronously*, with by default
274
+
// a small delay if those data are small
275
+
// because Nagle is around (~200ms)
276
+
// unless client.setNoDelay(true) was called.
277
+
//
278
+
// In any case client.write() will *never* block here
279
+
}
280
+
else
281
+
{
282
+
// or we can send but it will take time because data are too
283
+
// big to be asynchronously bufferized: TCP needs to receive
284
+
// some ACKs to release its buffers.
285
+
// That means that write() will block until it receives
286
+
// authorization to send because we are not in a
287
+
// multitasking environment
288
+
289
+
// It is always OK to do this, client.availableForWrite() is
290
+
// only needed when efficiency is a priority and when data
291
+
// to send can wait where they currently are, especially
292
+
// when they are in another tcp client.
293
+
294
+
// Flow control:
295
+
// It is also important to know that the ACKs we are sending
296
+
// to remote are directly generated from client.read().
297
+
// It means that:
298
+
// Not immediately reading available data can be good for
299
+
// flow control and avoid useless memory filling/overflow by
300
+
// preventing peer from sending more data, and slow down
301
+
// incoming bandwidth
302
+
// (tcp is really a nice and efficient beast)
303
+
}
304
+
}
305
+
306
+
// this is necessary for long duration loops (harmless otherwise)
0 commit comments