[lwip-devel] [patch #10013] tcp_in: Flag the pcb as closing if TCP_EVENT_CLOSED refused

[David Cermak]

Follow-up Comment #2, patch #10013 (project lwip):

Thanks for the feedback. Yes, I see. I just tried to have the SM  recover from
this state using a minimal changeset, but was in fact fixing the symptoms, not
the bug.

PTAL at the reworked patch. Added a new "pcb->flag: TF_REFUSED_DATA", if set,
it means that some `TCP_EVENT_...()` failed (if some data associated with the
event, "pcb->refused_data" still holds the pbuf).

I've decided against extending the `refused_data` field with enum values for
TCP_EVENT_CLOSED, TCP_EVENT_RECV, since it would make the `pcb` struct bigger,
or needed an extra allocation. Could have also allocated an empty pbuf to hold
the flags (as it's done for the FIN with data), but still an extra allocation
(even in this unlikely case). I think that using the `(pcb->flags &
TF_REFUSED_DATA)` is the most compact solution, and more or less clean, too.

Now we have these three situations:
1) TCP_EVENT_RECV only: Post the refused_data next time -- no change
2) both TCP_EVENT_CLOSED and TCP_EVENT_RECV: Post the refused data first, then
the closed event -- no change
3) TCP_EVENT_CLOSED only: Post the null/EOF event (TCP_EVENT_RECV(NULL) is
equivalent -- newly added
Still need to differentiate between 2 and 3, since for 2 we have to postpone
the data event to come before the EOF event



(file #51036)
    _______________________________________________________

Additional Item Attachment:

File name: tcp-Use-TF_REFUSED_DATA-flag-to-indicate-pcb-refused.patch Size:9
KB
   
<https://file.savannah.nongnu.org/file/tcp-Use-TF_REFUSED_DATA-flag-to-indicate-pcb-refused.patch?file_id=51036>



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/patch/?10013>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/