[lwip-devel] [task #7675] Enable to refuse data on a TCP_EVENT_RECV call

[Frédéric Bernon]

URL:
  <http://savannah.nongnu.org/task/?7675>

                 Summary: Enable to refuse data on a TCP_EVENT_RECV call
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: fbernon
            Submitted on: dimanche 13.01.2008 à 13:30
                Category: None
         Should Start On: dimanche 13.01.2008 à 00:00
   Should be Finished on: dimanche 13.01.2008 à 00:00
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
                  Effort: 0.00

    _______________________________________________________

Details:

In task #7490, "Add return value to sys_mbox_post", we have see a problem
with the recv_tcp callback (call by TCP_EVENT_RECV in tcp_in.c, line 308):
when this callback is invoked, if the pbuf in argument can't be processed
(mbox full, or any other reason), there is nothing in the tcp_input code to
process this case: the pbuf will not be give in the next call to
TCP_EVENT_RECV (so, we lost datas, which is not reliable like tcp should be).

In task #7490, Simon proposed : "So either we have to solve this in tcp_in.c
or set the netconn that missed a packet to a fatal error mode (and maybe
already abort the pcb?) so that the connection is aborted. "

I proposed: "Perhaps add a pbuf* in the tcp_pcb where we could keep the data
to pass to TCP_EVENT_RECV when this one return an error, and we retry to pass
it to the next tcp_input call?"

In all cases, I think the problem is more a design problem of the callback
raw api: I think we should be able to stop to receive any new datas on a
tcp_pcb when this one is "full".






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?7675>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/