patchlwIP - A Lightweight TCP/IP stack - Patches: patch #6723, Add option UDP_EXT_RECV_CALLBACK...

 
 

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

patch #6723: Add option UDP_EXT_RECV_CALLBACK to enable new API function udp_ext_recv()

Submitted by:  Jakob Stoklund Olesen <stoklund>
Submitted on:  Wed 14 Jan 2009 11:46:32 AM UTC  
 
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  Simon Goldschmidt <goldsimon> Open/Closed:  Closed
Planned Release:  1.4.0

( Jump to the original submission)

Tue 05 May 2009 06:41:25 PM UTC, comment #13: 

Thank you, Simon. I agree with your thoughts regarding multithreading and TLS.

Jakob Stoklund Olesen <stoklund>
Project Member
Tue 05 May 2009 05:51:19 PM UTC, comment #12: 

Done by adding 2 new functions:
struct netif *ip_current_netif();
const struct ip_hdr *ip_current_header();

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 05 May 2009 05:46:16 PM UTC, comment #11: 

I had another thought about this: the parameter pcb does of course make no sense, because ip_input does not know any pcbs. We could leave away the parameter altogether, but that would make it difficult to receive in multiple threads in the future (a thing I still have in the back of my head: being able to prioritize one connection over another, splitted by the hardware or the driver into multiple input queues).

But then again, if we (or I) ever do that, we could save the current netif/ip-header into thread-local storage - a thing we already need for the timeouts now.

I'll check it in without the parameter 'pcb'.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 05 May 2009 08:16:52 AM UTC, comment #10: 

Yes, looks OK to me.

Kieran Mansley <kieranm>
Project Member
Mon 04 May 2009 06:51:44 PM UTC, comment #9: 

Just like I thought to implement it. I would just like to get a comment about the 'new' solution from Kieran and/or Jifl, since they took quite a big part in the discussion leading to the initial post.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 04 May 2009 07:51:24 AM UTC, comment #8: 

OK, I have attached a new patch that implements Simon's idea. It works well enough for my purposes, so I think we should go that way.

(file #18081)

Jakob Stoklund Olesen <stoklund>
Project Member
Sun 03 May 2009 10:36:14 AM UTC, comment #7: 

> So something like this:


I guess, yes. Although it doesn't look as clean (because of the void pointers), I think it's the only way to use it for all IP-based protocols.

> Would you like me to submit a new patch?


That would be great as I'm still working on the other bugs...

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sun 03 May 2009 10:20:08 AM UTC, comment #6: 

So something like this:

const struct ip_hdr *ip_current_header(const void *pcb);
struct netif *ip_current_netif(const void *pcb);

Would you like me to submit a new patch? I think I can find the time to test it Monday.

Jakob Stoklund Olesen <stoklund>
Project Member
Sun 03 May 2009 10:09:18 AM UTC, comment #5: 

> you loose the opportunity to use these functions in raw and tcp callbacks.


We have the common members IP_PCB for that. Although I still think that could lead to poor portability (including a struct ip_pcb at the start of udp/tcp/raw_pcb could be better), I think it should work for now.

As long as we're not through with 1.3.1, why not? These are only additional functions, after all.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sun 03 May 2009 07:49:43 AM UTC, comment #4: 

Fine by me - except you loose the opportunity to use these functions in raw and tcp callbacks. The interface could be used for TCP access control, for instance.

Alternatively, the pcb argument could be a void* so udp_pcb, tcp_pcb, and raw_pcb can all be passed.

This way of doing it is much less invasive than the patch. Perhaps it could go in 1.3.1?

Jakob Stoklund Olesen <stoklund>
Project Member
Sun 03 May 2009 07:31:28 AM UTC, comment #3: 

I'd give the pcb as an argument though: that way, we are free to move the current-header and current-netif into the pcb, later, if we want that, instead of being tied to saving it global.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sun 03 May 2009 06:27:40 AM UTC, comment #2: 

How about doing this at the IP level? Then raw PCBs can also benefit.

const struct ip_hdr *ip_current_header();
struct netif *ip_current_netif();

These functions should return NULL when ip_input is not on the call stack.

This would be good enough for my needs.

Note: If this functionality is available unconditionally, it is possible to remove the DHCP-specific code from udp.c.

Jakob Stoklund Olesen <stoklund>
Project Member
Sat 02 May 2009 09:02:09 PM UTC, comment #1: 

Just a thought on that: wouldn't it be more backwards-compatible and maybe cleaner (because of having less options) if we implemented a function that received the additional parameters for the pcb?

We could implement that in global variables or cached in the pcbs. I know it might not be cleaner from the application coding point of view, but it would save some #ifs and the flag test (to get the type of input function to call).

We could implement something like

err_t udp_get_input_info(struct udp_pcb pcb, struct ip_addr* src, atruct ip_hdr* iphdr, struct netif* inp);

to get the info, and the callback would stay the same for old and new applications.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 14 Jan 2009 11:46:32 AM UTC, original submission:  

A UDP pcb can have either an extended or a normal receive callback,
not both.  The extended callback has access to the IP header and the receiving interface. It is meant for UDP applications with special requirements.

Please see discussion beginning here:
http://lists.gnu.org/archive/html/lwip-devel/2009-01/msg00020.html

Jakob Stoklund Olesen <stoklund>
Project Member

 

Attached Files
file #18081:  ip-callback-info.patch added by stoklund (3KiB - text/x-patch - Alternative, less intrusive patch)
file #17256:  udp-extend-callback added by stoklund (8KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by kieranm (Updated the item)
  • -email is unavailable- added by stoklund (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-05-05 goldsimon StatusNone => Done
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed
    2009-05-04 stoklund Attached File- => Added ip-callback-info.patch, #18081
    2009-04-03 kieranm Planned ReleaseNone => 1.4.0
    2009-01-14 stoklund Attached File- => Added udp-extend-callback, #17256

    Back to the top


    Powered by Savane 3.5