[Xorp-hackers] Events and sockets in XORP

[Victor Faion]

On Sat, Jan 31, 2009 at 12:58, Pavlin Radoslavov
<pavlin at icsi.berkeley.edu> wrote:
>> I was trying to use XORP to create an application layer protocol with
>> the routers sending messages to each other over TCP sockets. I created
>> a XORP process following the guide about static routes, but I still
>> don't understand some things such as when functions of the process get
>> called. For example in the main function of the process there is an
>> event loop. How do the events correspond to functions called, and how
>> do you generate events? For example how would you trigger a function
>> call on receipt of a message? Also a more general question, I am
>> trying to use the socket library provided by XORP and run this code on
>> top of XORP, but I'm not sure if I should be making a XORP process to
>> do this or is there another way of using the XORP socket library? (I
>> also wanted to extract the shortest paths calculated by OSPF and use
>> these to open socket connections instead of sending packets.)
>
> XORP processes are event-driven: you use the eventloop to
> register callbacks for various events: timer expires, socket ready
> for I/O, etc.
> In other words, the functions/methods in your process are event
> handlers. It is very important that those handlers return
> promptly to the eventloop, otherwise the process operation will be
> disturbed (background XRL timers might timeout, etc).
>
> Unlike other routing processes, the static routes process just
> pushes the user configured routes, and doesn't send/receive any
> control traffic.
> You might want to have a look at RIP/RIPng for example which uses
> UDP control packets.
>
> To send/receive TCP you can do it via the FEA so you don't have to
> deal with sockets, etc.
> Basically, you need to use the xrl/interfaces/socket4.xif XRL API to
> register with the FEA to send/receive TCP.
> Then in your protocol you need to implement the receiving (target)
> side of socket4_user.xif .
> The XRL library itself will take care of the rest: on reception it
> will call the appropriate socket4_user.xif method.
> Once you process the event, just return back to the eventloop.
>

I implemented these functions (basically just printing out their parameters):

socket4_user_0_1_recv_event
socket4_user_0_1_inbound_connect_event
socket4_user_0_1_outgoing_connect_event
socket4_user_0_1_disconnect_event
socket4_user_0_1_error_event

I'm not sure how to register with the FEA, I was trying to call
send_tcp_listen in my startup function, but I didn't know what
parameters to use (especially the sockid).

The documentation on that function says:
Listen for inbound connections on socket. When a connection request
received the socket creator will receive notification through
socket4_user/0.1/inbound_connect_event.

Does this mean the callback parameter should be my implementation of
inbound_connect_event, or is the callback passed just supposed to
generate some error if listening on a socket didn't succeed?

For the destination target name I was passing
"socket4/0.1/tcp_listen", but I'm not sure if this is the right thing
to use.

> If you have transmission timers that are triggered periodically,
> just call the "send" XRL (socket4.xif) and return back to the
> eventloop.
> The handlers for those timers are scheduled by using the EventLoop
> API (e.g., new_oneoff_after(), etc).
>
> If you need to use raw IP packets, then you can use the
> fea_rawpkt4.xif / fea_rawpkt4_client.xif API.
>
> Of course, you can create and use your own sockets, but then it is
> up to you to deal with the extra details: add the socket file
> descriptor to the eventoop (EventLoop::add_ioevent_cb()), buffer the
> received data, etc.
>
> Hope that helps,
> Pavlin
>
> P.S. I cannot answer the OSPF-related question because I am not
> familiar with the OSPF implementation details.
>

Thank you for the help, its beginning to make more sense :)