[Xorp-hackers] Remote finder: XRLs, or local ports?

[Steven Simpson]

On 23/02/11 11:51, Steven Simpson wrote:
> All our node needs to do now is iterate over the protected _listeners
> member inherited from XrlRouter, and get out the results of protocol()
> (e.g. "stcp") and address() (e.g. "127.0.0.1:1234").  These are sent to
> the resolver (e.g. as "stcp://127.0.0.1:1234"), which will discard items
> it can't use ("unix:...."), and translate 127.0.0.1 to the remote
> address of the calling connection.

It turns out that XrlStdRouter can't handle "stcp://" addresses.  It
seems to forward them to the finder, which has no knowledge of them, of
course.  *Is there a direct way of invoking an "stcp://" address?*

Here's one we're actually trying:

stcp://192.168.1.75:41706/eua_tci/0.1/dispatch?tci_id:bool=true&euaxrl:txt=finder://eua_ping_mp/eua_ping_mp/0.1/ping?address:ipv4%3D148.88.1.1&cbxrl:txt=stcp://127.0.0.1:49098/eua_tci/0.1/dispatch_callback?id:u32%3D0&cbpfx:bool=true&errxrl:bool=true&errpfx:bool=true


But we get:

WARNING xorp_rtrmgr:9371 XrlFinderTarget 
obj/i686-pc-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"192.168.1.75:41706" does not exist or is not enabled.



We're calling this from a target implementation class:

class XrlEuaTciNode : public XrlStdRouter,
		      DispatchCBs,
		      public XrlEuaTciTargetBase,
		      public ServiceBase ...


That is, a method of this class calls:

  this->send(the_xrl_above, our_callback)

...so we're using the inherited XrlStdRouter, which is configured to
talk to the local finder.  Even the stcp:// XRL is submitted to the
finder, giving the error.  So, if it's possible, this doesn't seem to be
the right way to call stcp directly.


> This method will allow us to progress, but the remote finder:// option
> might still be useful to us, btw, if there's an answer to that.

This option doesn't seem to exist, but I had a look at
"xorp/libxipc/call_xrl.cc".  It creates an XrlStdRouter for a given
finder address.

If there's no direct way to call an stcp XRL, we will resort to using
something like this instead.  I think we will have to create a
map<finderAddress, XrlStdRouter>, and cache existing XrlStdRouters, so
their callbacks remain valid.

Cheers,

Steven

--