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

[Mark Doll]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig180BEFD54C3FEDCDEB982933
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks, hi Pavlin!

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?

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.

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.

--------------enig180BEFD54C3FEDCDEB982933
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkNqHocACgkQIA3R24S6bIEQJACfUKiuTEfkFbC3zAateEF0ApH2
/goAoIOWByC6EoWDF+a+Ca9sWPQ2y/kZ
=0Lv1
-----END PGP SIGNATURE-----

--------------enig180BEFD54C3FEDCDEB982933--