[Xorp-hackers] How to add UDP socket I/O to PIM

Pavlin Radoslavov pavlin@icir.org
Thu, 03 Nov 2005 17:30:47 -0800


> Socket programming in C is normally quite easy and straight
> forward, but within XORP, I'm totally lost.
> 
> I'm browsing the XORP sources for some while now, have done some
> modifications (see P.S.) and am now trying to figure out how XORP
> modules implement XRL communication in general and socket I/O in
> particular. I think I've understood how to use XRLs and how they
> work (i. e. this magic callback factory function or why you can
> savely destroy your XrlSomeInterfaceV0p1Client object directly
> after XRL invocation but before receiving the callback with the
> results). But I'm still quite unsure on how to do queueing and
> buffering of those XRL calls within a XORP module and coordination
> via the eventloop, especially within PIM, which I'm trying to
> modify now.
> 
> My question is: Has anybody a howto on this or can give me a few
> lines of documented sample code which I can reuse?

The docs/xorpdev_101 document contains some information about XORP
processes and XRLs, but the question you are asking about is a bit
too specific to be answered in that document.

> Until now I've copy&pasted parts of RIP's socket4/6 and
> socket4/6_user XRL interface usage/implementation (the complete
> RIP socket I/O code is unadequately complex because I only have
> one UDP socket, one neighbor (the BB) and no multicast). Currently
> I think about something similar to PIM's queueing (class
> XrlPimNode::XrlTaskBase and derived classes) that are used in
> communication with the MFEA.

PIM itself doesn't use UDP, hence the code doesn't contain anything
about sending/receiving UDP packets.

The model to use UDP for sending/receiving messages is similar to C
sockets, except that the API is more abstract and sometimes a number
of operations are combined with a single one.
First, have a look at the xrl/interfaces/socket{4,6}.xif and the
xrl/interfaces/socket{4,6}_user.xif XRL interface files.

The socket{4,6}.xif interface specifies the API to open a TCP or UDP
socket and to send data. The socket{4,6}_user.xif interface is the
API for receiving data and for error notification.

The PIM module needs to implement the socket{4,6}_user/0.1 XRL
target interface so it can receive the XRLs. The xorpdev_101
document should explain how to do that.

Also, inside the PIM module you need to call the appropriate XRLs
to open the UDP socket. E.g., use udp_open_and_bind to get a handler
for the opened socket, and then use that handler to join a multicast
group (udp_join_group), send data by the "send_to" XRL, etc.
Again, the xorpdev_101 should contain info how to call XRLs in
general, and the RIP code itself shows you how to do it for those
particular XRLs.

The PIM's queueing (class XrlPimNode::XrlTaskBase) is needed primary
to ensure that different type XRLs are transmitted in-order to the
MFEA . In your case probably it doesn't matter because the UDP
packets will be going to a different entity (to the BB via the FEA),
but for the sake of being uniform with the XRL transmission from PIM
I would still recommend to use that queue.

Hope that helps,
Pavlin

> I don't know if this is the right way to do it, or if there's an
> easier way to implement this. So I'll really appreciate any
> help/hint/reassurance whatsoever. I think I'm lost in option space
> and can't see the wood for the trees...
> 
> Regards, Mark.
> 
> P.S.: Some background about what I'm doing:
> I'm implementing a simple extension to PIM, in which the PIM
> daemon informs a bandwidth broker (BB) by (repeatedly) sending a
> UDP datagram to the BB about an (in respect to QoS) unconfigured
> MFC entry containing all necessary info for its descision
> process. The BB in turn answers with one UDP datagram to tell PIM
> either to forward packets with unmodified diffserv codepoint or to
> reconfigure the multicast forwarding cache entry in the (FreeBSD)
> kernel so tha all packets are remarked to lower effort (RFC 3662)
> to handle the NRS problem (RFC 3754). It's a bit more complex than
> this, but that's the basic scheme. The modifications to
> FreeBSD/routing socket/MFEA are done, but the UDP socket to
> communicate with the BB is still missing. Of course, in the future
> plain UDP will be replaced by a real signaling protocol and
> probably a redesign of the complete implementation. But for a
> basic evaluation of the concept plain UDP is sufficient.