tasklwIP - A Lightweight TCP/IP stack - Tasks: task #7525, Implement TCP listen backlog

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #7525: Implement TCP listen backlog

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Sun 16 Dec 2007 04:53:05 PM UTC
   
 
Category:  None Should Start On:  Sun 16 Dec 2007 12:00:00 AM UTC
Should be Finished on:  Sun 16 Dec 2007 12:00:00 AM UTC Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Percent Complete:  100%
Open/Closed:  Closed Planned Release:  1.3.0
Effort:  0.00

Jump to the original submission

Sun 06 Jan 2008 07:39:33 PM UTC, comment #37: 

Since there is no objections, I close it...

Frédéric Bernon <fbernon>
Group Member
Sun 06 Jan 2008 11:02:41 AM UTC, comment #36: 


>Yes, I'm agree that a strict respect of opengroup specifications can be implemented easily.


Sorry, I would like to write "can't be"

Frédéric Bernon <fbernon>
Group Member
Sat 05 Jan 2008 06:42:27 PM UTC, comment #35: 

Yes, I'm agree that a strict respect of opengroup specifications can be implemented easily.

So, I suppose we can close this task now. No objections?

Frédéric Bernon <fbernon>
Group Member
Sat 05 Jan 2008 06:34:04 PM UTC, comment #34: 

Thanks Frederic!

It just occurred to me about backlog = 0, that from the specification, the implication is that it is valid for the backlog queue length to be 0. I think this would mean that a connection is only accepted if there is already an accept() call in progress and blocked.

I don't think we can sensibly implement that semantic though, so in that case it's better to just leave things as they are which is close enough.

Jonathan Larmour <jifl>
Group Member
Fri 04 Jan 2008 10:29:35 PM UTC, comment #33: 

Ok, it's check in. Jonathan, I have modify the CHANGELOG like you have proposed. About "backlog < 0", I have limited in the u8_t range in lwip_listen, like proposed in comment #31. If backlog = 0, it is set like the smallest queue.

I don't have other changes for this task. Can we close it?


Frédéric Bernon <fbernon>
Group Member
Fri 04 Jan 2008 02:11:47 PM UTC, comment #32: 

I think Frederic's suggestion is right, given what the opengroup URL says.

So I don't think we should have 0 == max anywhere.

The rest of the change is fine as far as I'm concerned. Frederic, when you check that in, I can check in the rawapi.txt change if you like, not that it makes much difference.

Jonathan Larmour <jifl>
Group Member
Fri 04 Jan 2008 01:04:39 PM UTC, comment #31: 


>About "he listen backlog (0 = max)", I also thought about that. I think it is OK to leave it 0 = DEFAULT if it's well documented. The only problem I see here is that socket users can't set a maximum value (since socket API uses int while we use u8_t).


For socket API, perhaps we could remove the asserts and replace if by a "clamping" code like that in lwip_listen :

if (backlog<0) {
  backlog=0;
}
if (backlog>0xff) {
  backlog=0xff;
}

Frédéric Bernon <fbernon>
Group Member
Fri 04 Jan 2008 11:08:43 AM UTC, comment #30: 

The patch seems fine to me (although sadly I don't have much time for lwIP at the moment and so couldn't study it in detail).

About "he listen backlog (0 = max)", I also thought about that. I think it is OK to leave it 0 = DEFAULT if it's well documented. The only problem I see here is that socket users can't set a maximum value (since socket API uses int while we use u8_t).

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 Jan 2008 08:15:12 AM UTC, comment #29: 


>I think an API should be consistent (which is why tcp_accepted(pcb) becomes empty if the option is off)


Yes, I put an empty define to avoid to have to use TCP_LISTEN_BACKLOG in raw api samples.

>and the way it was written implies it's not possible to call tcp_accepted if TCP_LISTEN_BACKLOG=0.


Ok. Modify the CHANGELOG is you have time, else, I will do it in the weekend.

For the other parts, can I check in the patch ? I also thought to "the listen backlog (0 = max),": in fact, I don't set it to max (0xff) but to TCP_DEFAULT_LISTEN_BACKLOG (which is 0xff by default, but could be changed).

Other think: in http://www.opengroup.org/onlinepubs/007908799/xns/listen.html, we could read : "If listen() is called with a backlog argument value that is less than 0, the function sets the length of the socket's listen queue to 0.". So, perhaps we should add in lwip_listen a check like "if (backlog<0) backlog=0;" and remove one of the assert, and, in tcp_listen_with_backlog, write :

lpcb->backlog = (backlog ? backlog : 1);

and change the netconn_listen comment.

Thoughts?





Frédéric Bernon <fbernon>
Group Member
Fri 04 Jan 2008 01:20:05 AM UTC, comment #28: 

Hi Frederic,

Thanks! I have just one comment which is only the documentation:

I would prefer to document the call to tcp_accepted as a proper part of the raw API, rather than just for TCP_LISTEN_BACKLOG=1. I think an API should be consistent (which is why tcp_accepted(pcb) becomes empty if the option is off) and the way it was written implies it's not possible to call tcp_accepted if TCP_LISTEN_BACKLOG=0.

So I suggest the following. Sorry if Savannah messes the formatting:
-=-=-=-=-=-=-=-=-=-=-=-=-=-
- struct tcp_pcb *tcp_listen_with_backlog(struct tcp_pcb *pcb, u8_t backlog)



  Same as tcp_listen, but limits the number of outstanding connections in the listen queue to the value specified by the backlog argument.

  To use it, you need to define TCP_LISTEN_BACKLOG to 1 in lwipopts.h.

-  void tcp_accepted(struct tcp_pcb *pcb)

Inform lwIP that an incoming connection
has been accepted. This would usually be called from the accept callback. This allows lwIP to perform housekeeping tasks, such as allowing further incoming connections to be queued in the listen backlog.
-=-=-=-=-=-=-=-=-=-=-=-=-=-

This would also allow us to do further different things in tcp_accepted in the future if there is ever a need, without changing the API description.

Jonathan Larmour <jifl>
Group Member
Fri 04 Jan 2008 12:30:21 AM UTC, comment #27: 

I attach a patch about remarks in comments #23-#26. Is there any objections to check in it?


(file #14744)

Frédéric Bernon <fbernon>
Group Member
Sun 23 Dec 2007 11:14:23 AM UTC, comment #26: 


>@param backlog (ATTENTION: this is not implemented, yet!)


in lwip_listen, we can change this javadoc comment

Frédéric Bernon <fbernon>
Group Member
Sun 23 Dec 2007 11:12:55 AM UTC, comment #25: 


>We should move asserts from lwip_listen to netconn_listen_with_backlog, like this, both API got them


Sorry, forget this remark, I didn't see the backlog parameter in netconn_listen_with_backlog was u8_t now...

Frédéric Bernon <fbernon>
Group Member
Sat 22 Dec 2007 10:29:44 PM UTC, comment #24: 

Other remarks :

- We should move asserts from lwip_listen to netconn_listen_with_backlog, like this, both API got them

- We don't have to forget to document rawapi.txt when this task will be ended.

Frédéric Bernon <fbernon>
Group Member
Sat 22 Dec 2007 10:01:56 PM UTC, comment #23: 

Some remarks about last check in:

- in api_lib.c, we can read in the comment "@param backlog the listen backlog (0 = max), only used if LWIP_LISTEN_BACKLOG==1", but I don't see where 0 got such behavior. More, if backlog = 0, lwip_listen will raise an assert "LWIP_ASSERT("backlog must be between 0 and 255", backlog > 0);".

- We have to to set LWIP_LISTEN_BACKLOG to 0 per default to avoid to break the default behavior. Why finally enable it per default in opt.h?

- jifl suggested in comment #14 to do the same api change (but with compatibility) for tcp_listen. It would give something like :

struct tcp_pcb * tcp_listen_with_backlog(struct tcp_pcb *pcb, u8_t backlog);
#define tcp_listen(pcb) tcp_listen_with_backlog(pcb, LWIP_MAX_LISTEN_BACKLOG);

In this case, we could remove tcp_backlog macro. I'm in flavor of this solution.

- LWIP_DEFAULT_LISTEN_BACKLOG is a best name than LWIP_MAX_LISTEN_BACKLOG, but since this feature is now available in raw API, perhaps we should rename these options in TCP_LISTEN_BACKLOG and TCP_DEFAULT_LISTEN_BACKLOG ?


Frédéric Bernon <fbernon>
Group Member
Fri 21 Dec 2007 04:49:53 PM UTC, comment #22: 

I've checked in the last patch + missing things (lwip_listen, netconn_listen...). Note I've changed LWIP_MAX_LISTEN_BACKLOG to LWIP_DEFAULT_LISTEN_BACKLOG (which is used in tcp_listen() and netconn_listen() (without backlog)) since I don't think checking the argument 'backlog' agains MAX_LISTEN_BACKLOG makes mutch sense...

Simon Goldschmidt <goldsimon>
Group administrator
Fri 21 Dec 2007 12:39:08 PM UTC, comment #21: 


>> I'd prefer to do that since the change is kind of related to the
>> SYS_ARCH_GET/SET macros from bug #21698...
>
> Oh, perhaps I don't understand you? Do you prefer your patch
> (which use SYS_ARCH_GET/SET macros) or the last one (which doesn't use them) ?


Oh, I meant the last patch... But it seems I looked at the wrong one just before writing comment #18...

Anyway, let's include this now.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 21 Dec 2007 11:36:18 AM UTC, comment #20: 

I think this looks good.

I think it would be good for this to sneak into 1.3.0 since 1.3.0 is still not fully frozen, and this isn't so major in how it could destabilise the source tree. Certainly nothing to the persist timer and silly window avoidance changes!

Jonathan Larmour <jifl>
Group Member
Fri 21 Dec 2007 11:28:28 AM UTC, comment #19: 


>so I think I'd prefer to turn it off by default.


I'm agree with you

>Should we integrate it now (before 1.3.0)?


I think we can if we got a consensus.

>I'd prefer to do that since the change is kind of related to the SYS_ARCH_GET/SET macros from bug #21698...


Oh, perhaps I don't understand you? Do you prefer your patch (which use SYS_ARCH_GET/SET macros) or the last one (which doesn't use them) ?

Frédéric Bernon <fbernon>
Group Member
Fri 21 Dec 2007 10:38:20 AM UTC, comment #18: 

OK, if you put it that way... OK with me.

Then the only problem is the default behaviour: Would it be turned on or off? Turning it on by default would allow the backlog setting for the sockets API by default but break old raw applications, so I think I'd prefer to turn it off by default.

Should we integrate it now (before 1.3.0)? I'd prefer to do that since the change is kind of related to the SYS_ARCH_GET/SET macros from bug #21698...

Simon Goldschmidt <goldsimon>
Group administrator
Thu 20 Dec 2007 02:01:24 PM UTC, comment #17: 


>would raw API apps decrease it in their accept callback


I don't think it's mandatory for a raw api user to call tcp_accepted in accept_callback: he could store them in a list or table, and start to use them later. So, to my point of view, even raw api users could use this feature if they need.


Frédéric Bernon <fbernon>
Group Member
Thu 20 Dec 2007 01:55:59 PM UTC, comment #16: 

In opt.h:

#ifndef LWIP_MAX_LISTEN_BACKLOG
#define LWIP_MAX_LISTEN_BACKLOG 0xff
#endif

+ what jifl suggests (execpt backlog type):

err_t
netconn_listen_with_backlog(struct netconn *conn, u8_t backlog);
#define netconn_listen(conn) netconn_listen_with_backlog(conn, LWIP_MAX_LISTEN_BACKLOG);

+ some assert and sanity check

Frédéric Bernon <fbernon>
Group Member
Thu 20 Dec 2007 11:52:04 AM UTC, comment #15: 


> #if LWIP_LISTEN_BACKLOG
> # define LWIP_MAX_LISTEN_BACKLOG LWIP_LISTEN_BACKLOG
> #else
> # define LWIP_MAX_LISTEN_BACKLOG 1
> #endif
>
> err_t netconn_listen_with_backlog(struct netconn *conn, int backlog);
> #define netconn_listen(conn) netconn_listen_with_backlog(conn, LWIP_MAX_LISTEN_BACKLOG);


That would change the existing behaviour from allowing a maximum number of connections to only one connection... I don't know if that's good or not: it could break existing applications but it prevents overflooding an acceptmbox...

> For "to_accept", how about "accepts_pending"


But raw API apps can't have any accepts pending, can they? How would a raw API app work with this new feature? Since 'to_accept' is increased in tcp_listen_input, would raw API apps decrease it in their accept callback? So 'to_accept' it would always be 0 or 1 for raw API apps? If it's like that, why don't we include the counter in the netconn part and only have a flag 'accept_allowed' in the raw part? To me it feels kind of weird including the counter in the pcb when it can only be used in the netconn API (unless I'm wrong with that assumption, of course :)

Simon Goldschmidt <goldsimon>
Group administrator
Thu 20 Dec 2007 11:06:44 AM UTC, comment #14: 

For "to_accept", how about "accepts_pending"

I think having an API that changes depending on configuration is worse than just changing the API. But I think a better option may be:

#if LWIP_LISTEN_BACKLOG
# define LWIP_MAX_LISTEN_BACKLOG LWIP_LISTEN_BACKLOG
#else
# define LWIP_MAX_LISTEN_BACKLOG 1
#endif

err_t
netconn_listen_with_backlog(struct netconn *conn, int backlog);
#define netconn_listen(conn) netconn_listen_with_backlog(conn, LWIP_MAX_LISTEN_BACKLOG);


and in socket.h:
#define SOMAXCONN LWIP_MAX_LISTEN_BACKLOG

Something similar could be done with tcp_listen() I guess

Jonathan Larmour <jifl>
Group Member
Wed 19 Dec 2007 10:02:30 PM UTC, comment #13: 

I attach a patch file (without the changes in lwip_listen and netconn_listen, which could be the same than your patch). You can see where are the use of "to_accept" (which can be rename to something better) and "backlog".

Note I avoid to change tcp_listen, because adding a "backlog" parameter to this function will make mandatory to update all codes (even contrib/apps) and cause a API breakage.

In comment #1, I suggested to changes "listen" API like this:

err_t
#if LWIP_LISTEN_BACKLOG
netconn_listen(struct netconn *conn, int backlog)
#else
netconn_listen(struct netconn *conn)
#endif /* LWIP_LISTEN_BACKLOG */

But in fact, it's not really better because it would also make mandatory to use LWIP_LISTEN_BACKLOG option in contrib code, and it's not very "nice".

I don't know what would be the best solution to avoid API breakage and avoid to directly use LWIP_LISTEN_BACKLOG option in samples.



(file #14671)

Frédéric Bernon <fbernon>
Group Member
Wed 19 Dec 2007 02:55:22 PM UTC, comment #12: 

I don't really like do_recv being used for that, but as Jonathan said, it's probably OK to save space...

As for the rest: I didn't have the time to test it and I must say I couldn't really follow your ideas... Could you make it clear to me where you want to increase, decrease and check a counter? Or did you want a blocked/unblocked flag only??

I would want to make sure that this change doesn't break existing raw api applications.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 19 Dec 2007 02:48:36 PM UTC, comment #11: 


>Ah, I see what you mean now. I guess overloading do_recv might save a little code, so that seems fine then. I presume that the API message would be sent directly from netconn_accept, rather than by a dummy call of netconn_recv.


yes


Simon, thoughts?

Frédéric Bernon <fbernon>
Group Member
Wed 19 Dec 2007 01:46:15 PM UTC, comment #10: 

Ah, I see what you mean now. I guess overloading do_recv might save a little code, so that seems fine then. I presume that the API message would be sent directly from netconn_accept, rather than by a dummy call of netconn_recv.

In that case, I like this solution! Thanks Frédéric.

Jonathan Larmour <jifl>
Group Member
Wed 19 Dec 2007 08:11:35 AM UTC, comment #9: 


>tcp_accepted() could probably be a macro, for now at least.


Agree

>Although I'm not sure why we would change do_recv()? Can't we just call tcp_accepted() from accept_function() ?


?? In this case, the backlog would not be driven by the application, and should be always 0 or 1 (since each incoming tcp connected will callback accept_function, which call tcp_accepted). I think this is each time a netconn_accept is done we should increment the counter (in the same idea that the tcp window is increased each time the application read the data).


Frédéric Bernon <fbernon>
Group Member
Wed 19 Dec 2007 03:37:24 AM UTC, comment #8: 

It looks like Frederic was saying what I was thinking of pretty much. It seems like much less code.

tcp_accepted() could probably be a macro, for now at least.

Although I'm not sure why we would change do_recv()? Can't we just call tcp_accepted() from accept_function() ?

Of course we need to document tcp_accepted() for raw API users. But existing raw API users are unaffected - it only matters if they set LWIP_LISTEN_BACKLOG (although I'm sure it's best to have it defined as:
#if LWIP_LISTEN_BACKLOG
# define tcp_accepted(pcb) ((pcb)->to_accept--)
#else
# define tcp_accepted(pcb) /* NOTHING */
#endif
for API consistency).

Jonathan Larmour <jifl>
Group Member
Mon 17 Dec 2007 10:54:06 AM UTC, comment #7: 


>And need to do "to_accept++;" if TCP_EVENT_ACCEPT return ERR_OK;


And need to do "to_accept++;" in  tcp_listen_input if tcp_alloc return a valid pcb.



Frédéric Bernon <fbernon>
Group Member
Mon 17 Dec 2007 10:49:01 AM UTC, comment #6: 

And need to do "to_accept++;" if TCP_EVENT_ACCEPT return ERR_OK;

Frédéric Bernon <fbernon>
Group Member
Mon 17 Dec 2007 10:42:12 AM UTC, comment #5: 

Attach a text file (could be more readable). Note this is not a patch file, it's just to show the difference (there is no initialize part by example).

(file #14643)

Frédéric Bernon <fbernon>
Group Member
Mon 17 Dec 2007 10:39:12 AM UTC, comment #4: 


>Doing it in accept_callback is definitively wrong, because for the client, connect succeeds but a send after that fails!

...

>but with the current code, this is done at the wrong time (after the new connection is already established).


It's not a so big problem, since the client should also process this case. But if it's not so "nice", it's more "lightweight" :)

Other solution (perhaps it's what jifl suggested): and if we use do_recv in the same spirit than "netconn_recv" for tcp part? In netconn_accept, we could do a do_recv to inform tcp raw api we fetch one of new connections. Checking the state in do_recv will allow to know if we inform that we read data or accept a new netconn ? Like this, we put new fields only in tcp_pcb_listen (a "u8_t backlog" and a "u8_t to_accept"):

struct tcp_pcb_listen { 
/* Common members of all PCB types */
  IP_PCB;
/* Protocol specific PCB members */
  TCP_PCB_COMMON(struct tcp_pcb_listen);

#if LWIP_CALLBACK_API
  /* Function to call when a listener has been connected.
   * @param arg user-supplied argument (tcp_pcb.callback_arg)
   * @param pcb a new tcp_pcb that now is connected
   * @param err an error argument (TODO: that is current always ERR_OK?)
   * @return ERR_OK: accept the new connection,
   *                 any other err_t abortsthe new connection
   */
  err_t (* accept)(void *arg, struct tcp_pcb *newpcb, err_t err);
#endif /* LWIP_CALLBACK_API */
#if LWIP_LISTEN_BACKLOG
  u8_t backlog;
  u8_t to_accept;
#endif /* LWIP_LISTEN_BACKLOG */
};


void
do_recv(struct api_msg_msg *msg)
{
#if LWIP_TCP
  if (!ERR_IS_FATAL(msg->conn->err)) {
    if (msg->conn->pcb.tcp != NULL) {
      if (msg->conn->type == NETCONN_TCP) {
        if (conn->pcb.tcp->state == LISTEN) {
#if LWIP_LISTEN_BACKLOG
          tcp_accepted((struct tcp_pcb_listen *)(msg->conn->pcb.tcp)); <<<<<<<< NEW
#endif /* LWIP_LISTEN_BACKLOG */
        } else {
          tcp_recved(msg->conn->pcb.tcp, msg->msg.r.len);
        }
      }
    }
  }
#endif /* LWIP_TCP */
  TCPIP_APIMSG_ACK(msg);
}

#if LWIP_LISTEN_BACKLOG
void
tcp_accepted(struct tcp_pcb_listen *pcb)
{ pcb->to_accept--;
}
#endif /* LWIP_LISTEN_BACKLOG */

static err_t
tcp_listen_input(struct tcp_pcb_listen *pcb)
{ ...
  } else if (flags & TCP_SYN) {
    LWIP_DEBUGF(TCP_DEBUG, ("TCP connection request %"U16_F" -> %"U16_F".\n", tcphdr->src, tcphdr->dest));
#if LWIP_LISTEN_BACKLOG
    if (pcb->to_accept>=pcb->backlog) {
      return ERR_ABRT;
    }
#endif /* LWIP_LISTEN_BACKLOG */   
  ...
}


Frédéric Bernon <fbernon>
Group Member
Mon 17 Dec 2007 07:30:55 AM UTC, comment #3: 


> Isn't it possible to use the same fields that for SO_RCVBUF ?


I thought of that and it would make sense, but it would have made the patch more complex, so I didn't add it there.

> Yes, but your solution is less "lightweight" than do the process in accept_callback.


Doing it in accept_callback is definitively wrong, because for the client, connect succeeds but a send after that fails!

> why not just integrate this support directly into the raw TCP functions, with the backlog and current count of waiters as part of the PCB? The netconn accept function can then directly change the count of waiters in the PCB as it accepts them.


That was my idea at first also, but we have a problem there: the counter would be modified from tcpip_thread as well as in netconn_accept (after receiving a new connection from acceptmbox). So either access to this counter would have to be locked (in tcp_in.c also, which is bad) or we would need a new function in api_msg.c do_accepted which would modify the counter in the context of tcpip_thread (more code).

On the other hand, the accept_allowed callback also allows usage from raw applications. A listen backlog is not really applicable for them, since they can only allow or disallow new connections but no hold connections in a queue (because of the callback design) - but with the current code, this is done at the wrong time (after the new connection is already established).

Simon Goldschmidt <goldsimon>
Group administrator
Sun 16 Dec 2007 09:44:23 PM UTC, comment #2: 

I haven't had a chance to look closely at this patch, but why not just integrate this support directly into the raw TCP functions, with the backlog and current count of waiters as part of the PCB? The netconn accept function can then directly change the count of waiters in the PCB as it accepts them.

As well as less code, the patch already needs two pointers in the TCP PCB, so having two u8_t's (ints are overkill for lwip) would take less space.

Jonathan Larmour <jifl>
Group Member
Sun 16 Dec 2007 07:55:37 PM UTC, comment #1: 


>which would also be good to integrate into the netconn API


Isn't it in your patch? I see it. But even if it cause a API breakage, I'm in flavor to add it. Else, the new parameter could be dependant of LWIP_LISTEN_BACKLOG:

err_t
#if LWIP_LISTEN_BACKLOG
netconn_listen(struct netconn *conn, int backlog)
#else
netconn_listen(struct netconn *conn)
#endif /* LWIP_LISTEN_BACKLOG */
{


>a) the maximum and current backlog per netconn (2 to 8 bytes per netconn)


Isn't it possible to use the same fields that for SO_RCVBUF ? Else, we increase size for all netconn, even if we have only one or two listening ones (I think that most of time, we have more netconn which are not in listen mode, than netconn which are).

>b) can not be done with the current TCP code: I previously thought this could be done by returning an error in the accept callback, but at this point, the new connection is already established. Instead, it is necessary to abort the setup of a new connection when the listening connection receives the SYN: in tcp_listen_input before tcp_alloc even creates a new pcb.


Yes, but your solution is less "lightweight" than do the process in accept_callback. Of course, the solution dependant of what we want ("lw" or "best behavior").




Frédéric Bernon <fbernon>
Group Member
Sun 16 Dec 2007 04:53:05 PM UTC, original submission:  

For the socket listen backlog (which would also be good to integrate into the netconn API) to work, we need

a) the maximum and current backlog per netconn (2 to 8 bytes per netconn) and
b) a way to send a RST to a new client instead of SYN+ACK if the backlog limit is reached.

It turns out that b) can not be done with the current TCP code: I previously thought this could be done by returning an error in the accept callback, but at this point, the new connection is already established. Instead, it is necessary to abort the setup of a new connection when the listening connection receives the SYN: in tcp_listen_input before tcp_alloc even creates a new pcb.

For that, I have included an 'accept_allowed' callback in tcp_listen_pcb (+ argument, which makes 8 bytes per listen pcb) in the attached patch (note that this patch makes use of the SYS_ARCH_GET... macros used for bug #21698).

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #14744:  backlog.patch added by fbernon (14KiB - application/octet-stream)
file #14671:  backlog.patch added by fbernon (6KiB - application/octet-stream)
file #14643:  backlog.txt added by fbernon (2KiB - text/plain)
file #14637:  lwip_backlog.patch added by goldsimon (9KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-04-08 goldsimon StatusReady For Test Done
    2008-01-06 fbernon Percent Complete90% 100%
        Open/ClosedOpen Closed
    2008-01-04 fbernon Percent Complete80% 90%
    2008-01-04 fbernon Attached File- Added backlog.patch, #14744
        Percent Complete70% 80%
    2007-12-22 fbernon Planned ReleaseNone 1.3.0
    2007-12-21 goldsimon StatusNone Ready For Test
        Percent Complete0% 70%
    2007-12-19 fbernon Attached File- Added backlog.patch, #14671
    2007-12-17 fbernon Attached File- Added backlog.txt, #14643
    2007-12-16 goldsimon Attached File- Added lwip_backlog.patch, #14637

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code