nashif
commented
7 years ago by Andrei Laperie:
Just like in GH-1840?focusedCommentId=18756&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18756 we won't be able to fix it for 1.9
Reported by Paul Sokolovsky:
Similar to GH-1840, there doesn't seem to be send window handling at all. That means we aren't good TCP citizens (or putting it more direct, we violate TCP standard), especially in the constrained devices area. If a peer tells us that it can receive only limited amount of data, we should comply, likewise if it asks us to pause sending at all (by setting its receive window=0). Instead, we currently bombard it with packets, draining its battery.
Note that this is related to GH-1839, and there're 2 constraints on the outgoing packet size: whole packet size should be under MTU, and data size should be under send window.
Handling send window with separate API calls like:
{code:java} send_buf = net_nbuf_get_tx(...); net_nbuf_append(send_buf, len, data); net_context_send(send_buf, ...); {code}
Isn't very straightforward. Instead, there should likely be as separate tcp_send call, which will consult and update send window, the send packet of suitable size "atomically".
(Imported from Jira ZEP-2000)