eluaRPC

[jrambo316]

What I would like to do is have multiple elua boards connect peer to peer as needed and communicate info / commands over whatever transport is available (e.g. serial, ethernet, etc.).

From reading the documentation, it seems that eluaRPC is currently limited to a Server / Client relationship where the desktop is the server and the elua board is the client and the desktop is dedicated to waiting for incoming connections.  

Is that correct? How possible and how big a project would it be to realize the stated goal above?

Thanks.
Jim

[jrambo316]

From reading the docs again, I think I had it backwards.  The elua board is the server and the client is the desktop?  My question is concerning:

rpc.server( transport_identifiers )
Start a blocking/captive RPC server, which will wait for incoming connections.

Does this mean that the elua board that wants to accept connections cannot do anything else except service incoming connections?  Is there any example code that shows the server side of the rpc connection in action?

Regards,
Jim

[Thiago Naves]

On Mar 21, 2012 12:57 PM, "jrambo316" <[hidden email]> wrote:
>
> What I would like to do is have multiple elua boards connect peer to peer as
> needed and communicate info / commands over whatever transport is available
> (e.g. serial, ethernet, etc.).
>
> From reading the documentation, it seems that eluaRPC is currently limited
> to a Server / Client relationship where the desktop is the server and the
> elua board is the client and the desktop is dedicated to waiting for
> incoming connections.
>
> Is that correct? How possible and how big a project would it be to realize
> the stated goal above?
>

Actually the eLua board is the server and the desktop is the client.

I think it should be fairly easy to make  a board client as well.

--
Thiago

> Thanks.
> Jim
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eluaRPC-tp7387837p7387837.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Markus Korber]

Thus spake jrambo316:

> From reading the docs again, I think I had it backwards.  The elua board is
> the server and the client is the desktop?  

Yes.

> My question is concerning:
>
> rpc.server( transport_identifiers )
> Start a blocking/captive RPC server, which will wait for incoming
> connections.
>
> Does this mean that the elua board that wants to accept connections cannot
> do anything else except service incoming connections?  

That's right.  However, you might want to have a look at 'rpc.listen',
'rpc.peek', and 'rpc.dispatch' which allow you to have an application
running and using RPC commands at the same time.

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jrambo316]

Please have a look at my question concerning the rpc.server.

In my application, every elua board would be constantly performing its own functions and connecting / receiving rpc connections as needed.  I would need to find another option if the rpc.server "blocked" the functions above just waiting for connections.

This may be a stupid question.  I can try and figure it out for myself if there is some example code I can analyze.  The only example I saw on the website was from the client perspective.

Is the "boot to eluaRPC" the only option to turn on the server or could it be turned on and off adhoc?

Thanks,
Jim

[jbsnyder]

On Fri, Mar 23, 2012 at 12:55 PM, jrambo316 <[hidden email]> wrote:
> Please have a look at my question concerning the rpc.server.

rpc.server is captive, ditto for the boot mode which just hops into that.

rpc.peek should allow you to check for waiting data without blocking,
telling it to dispatch when peek returns a 1 will attempt to handle a
pending request.

I've done some things like the following in the past to have a
redefinable "control" function that executes regularly, but shares
time with incoming RPC requests:

autorun.lua:
local state = {}
local stime

function control()
end

handle = rpc.listen(0,0)
stime = tmr.start(0)
while true do
   -- Check for pending RPC request
   if rpc.peek( handle ) then
     rpc.dispatch( handle )
   end
   control()
   tmr.delay( 1, 100000-tmr.gettimediff( 0, tmr.read(0), stime) )
   stime = tmr.start(0)
end

there's also an rpc.adispatch function that basically does the same ting as:
   if rpc.peek( handle ) then
     rpc.dispatch( handle )
   end

>
> In my application, every elua board would be constantly performing its own
> functions and connecting / receiving rpc connections as needed.  I would
> need to find another option if the rpc.server "blocked" the functions above
> just waiting for connections.
>
> This may be a stupid question.  I can try and figure it out for myself if
> there is some example code I can analyze.  The only example I saw on the
> website was from the client perspective.
>
> Is the "boot to eluaRPC" the only option to turn on the server or could it
> be turned on and off adhoc?

One can just execute the rpc.server() function form the Lua prompt,
you don't have to boot to it.  I don't think rpc.server() ever really
exits though on serial connections, so the peek/dispatch functions may
be more appealing.

Now as far as having two boards talk to each other, I _believe_ this
should work, but I have not tried it recently after we made some
additions that were needed to get this going.   If it doesn't
currently work, it may just be due to some assumptions in the uart
handling code.  If you do try this and it doesn't work I'd be happy to
try and work through any issues on that front.

Best.

-jsnyder

>
> Thanks,
> Jim
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eluaRPC-tp7387837p7399382.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: [phone]
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev