RPC over SOCK_STREAM
Locked
|
Hello,
I've been working on the implementation of RPC over Ethernet. I have been able to construct the luarpc instance on the PC, replacing the luarpc_desktop_uart.c code with socket code. I have also created luarpc_elua_net.c. So far, I have been able to establish a handshake between the micro and the PC. So, s, e = rpc.connect(“192.168.100.90”, 6655) returns without error and s corresponds to the slave. The luarpc instance on the PC is able to get values from the micro. So, pio = s.pio works, (pio corresponding to userdata). However, I ran into a few problems: pio.pin.setdir(###) does not return. It goes into a waiting state. I am sure the file descriptor returned by elua_accept(###) is valid. While tracing through the code, I realized that the state does not enter read_cmd_call(###). I can only wonder if there’s a problem with the code for transport_open_listener(###). Do you have any suggestions for me ? I could put up my test branch online. (Where can I put the code ?) Is someone willing to work on this ? I could use some help. Awaiting your response. Raman |
|
|
Hello list,
(getting back from the vacations ....) On Tue, Oct 4, 2011 at 11:55, raman <[hidden email]> wrote: Hello, Cool ! Thanks for sharing this ! I have been Do you have a github account of your own ? I suggest you clone eLua to a project of yours and work there. It makes it (very) easy for other developers to collaborate and also to eventually integrate the code into eLua (via Pull Requests). Awaiting your response. Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by raman
On Tue, Oct 4, 2011 at 9:55 AM, raman <[hidden email]> wrote:
> Hello, > > I've been working on the implementation of RPC over Ethernet. I have been > able to construct the luarpc instance on the PC, replacing the > luarpc_desktop_uart.c code with socket code. I have also created > luarpc_elua_net.c. So far, I have been able to establish a handshake between > the micro and the PC. So, s, e = rpc.connect(“192.168.100.90”, 6655) returns > without error and s corresponds to the slave. FYI, there is already desktop socket code here: https://github.com/jsnyder/luarpc > > The luarpc instance on the PC is able to get values from the micro. So, pio > = s.pio works, (pio corresponding to userdata). This doesn't actually send anything over the wire. The way subtables of the slave work is that they create helpers that can replay indexing over the wire when an action is requested like calling a function (call) or assignment (newindex). I suppose we could check these things when the helpers are created, but the slave/server will return errors if it can't index remotely when you try an operation that does require communication. So, if you get through the connect phase, it probably at least did a header exchange to establish the connection. > However, I ran into a few > problems: pio.pin.setdir(###) does not return. It goes into a waiting state. > I am sure the file descriptor returned by elua_accept(###) is valid. While > tracing through the code, I realized that the state does not enter > read_cmd_call(###). I can only wonder if there’s a problem with the code for > transport_open_listener(###). It would be nice to know if it gets into rpc_dispatch_helper(L, handle). Does the client send an RPC_READY back to the server? I'm guessing it does if it gets to that function at all and gets to a hung state. I suppose I stripped out the debug code, so that would need to be added in to display this on the fly on the desktop side. I can put this back and make it optional if you're not familiar enough with the code to put some instrumentation in? > > Do you have any suggestions for me ? > > I could put up my test branch online. (Where can I put the code ?) Is > someone willing to work on this ? I could use some help. I'd be more than willing to take a look at it. As Dado mentions, you could use github. Here's information on how to "fork" a repository after you have an account: http://help.github.com/fork-a-repo/ Depending on your familiarity with Git we could find some other way to transmit the changes as well. > > Awaiting your response. > > Raman > > > > -- > View this message in context: http://elua-development.2368040.n2.nabble.com/RPC-over-SOCK-STREAM-tp6858931p6858931.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 |
|
|
FYI, there is already desktop socket code here: https://github.com/jsnyder/luarpc Oops. I didn't check on this before. I will use this on my test branch. This doesn't actually send anything over the wire. The way subtables of the slave work is that they create helpers that can replay indexing over the wire when an action is requested like calling a function (call) or assignment (newindex). I suppose we could check these things when the helpers are created, but the slave/server will return errors if it can't index remotely when you try an operation that does require communication. Ah, great. That answers a lot of my questions. So, if you get through the connect phase, it probably at least did a header exchange to establish the connection. Yes, The initial header exchange works. > However, I ran into a few > problems: pio.pin.setdir(###) does not return. It goes into a waiting state. > I am sure the file descriptor returned by elua_accept(###) is valid. While > tracing through the code, I realized that the state does not enter > read_cmd_call(###). I can only wonder if there’s a problem with the code for > transport_open_listener(###). It would be nice to know if it gets into rpc_dispatch_helper(L, handle). Does the client send an RPC_READY back to the server? I'm guessing it does if it gets to that function at all and gets to a hung state. When I tried debugging, the control did not go through case: RPC_CMD_CALL. So, it doesn't send back the macro value to the server. I suppose I stripped out the debug code, so that would need to be added in to display this on the fly on the desktop side. I can put this back and make it optional if you're not familiar enough with the code to put some instrumentation in? The debug code would be of great help. I'm using term for a quick display of events happening on the server side. > > Do you have any suggestions for me ? > > I could put up my test branch online. (Where can I put the code ?) Is > someone willing to work on this ? I could use some help. I'd be more than willing to take a look at it. Awesome. I was involved with github for the SWIG project. I'll fork eLua, do the changes and request a pull. One more thing: I went though the previous post describing the issues with elua_uip.c Will this interfere with the performance of RPC over ethernet ? Do we have to do anything about this before ? Awaiting your response. Raman |
|
|
On Wed, Oct 5, 2011 at 2:46 PM, raman <[hidden email]> wrote:
> > FYI, there is already desktop socket code here: > https://github.com/jsnyder/luarpc > > Oops. I didn't check on this before. I will use this on my test branch. > > This doesn't actually send anything over the wire. The way subtables > of the slave work is that they create helpers that can replay indexing > over the wire when an action is requested like calling a function > (call) or assignment (newindex). I suppose we could check these > things when the helpers are created, but the slave/server will return > errors if it can't index remotely when you try an operation that does > require communication. > > Ah, great. That answers a lot of my questions. > > So, if you get through the connect phase, it probably at least did a > header exchange to establish the connection. > > Yes, The initial header exchange works. > >> However, I ran into a few >> problems: pio.pin.setdir(###) does not return. It goes into a waiting >> state. >> I am sure the file descriptor returned by elua_accept(###) is valid. While >> tracing through the code, I realized that the state does not enter >> read_cmd_call(###). I can only wonder if there’s a problem with the code >> for >> transport_open_listener(###). > > It would be nice to know if it gets into rpc_dispatch_helper(L, > handle). Does the client send an RPC_READY back to the server? I'm > guessing it does if it gets to that function at all and gets to a hung > state. > > When I tried debugging, the control did not go through case: RPC_CMD_CALL. > So, it doesn't send back the macro value to the server. Hmm.. that's interesting, and certainly tells us a bit about where things might be stuck. > > I suppose I stripped out the debug code, so that would need to be > added in to display this on the fly on the desktop side. I can put > this back and make it optional if you're not familiar enough with the > code to put some instrumentation in? > > The debug code would be of great help. I'm using term for a quick display of > events happening on the server side. OK. I'll look into sticking some of that back in. At different points I would have it spit out some details about generally what it was doing as well as sometimes doing dumps of all the data that was being sent. It sounds like even just full dumps might be useful since it bails/hangs so early. You can add to the transport_write_buffer and transport_read_buffer to watch each message that's received/sent from the perspective of the desktop machine quite easily. > >> >> Do you have any suggestions for me ? >> >> I could put up my test branch online. (Where can I put the code ?) Is >> someone willing to work on this ? I could use some help. > > I'd be more than willing to take a look at it. > Awesome. I was involved with github for the SWIG project. I'll fork eLua, do > the changes and request a pull. OK. I believe I should see this in my messages on GitHub when you do so. > > One more thing: > I went though the previous post describing the issues with elua_uip.c > Will this interfere with the performance of RPC over ethernet ? > Do we have to do anything about this before ? Well, I'm not sure. I haven't used TCP/IP on eLua a whole lot and so I'm not that familiar with the failure or problem modes that have been experienced. I think I understand a little of how they might happen based on what Bogdan has mentioned to me about what he's working on (which should improve functionality and add UDP support). I think that ultimately we might be best off if we can make it work with a stateless protocol like UDP, and handle missing data or failed data exchanges within LuaRPC, which is fairly careful about sending data back and forth (hence things like RPC_READY, which prevent the sender from just dumping lots of data to the microcontroller without knowing if there's a ready and waiting buffer). I believe that Bogdan is also fleshing out the UDP support within eLua a bit more with his branch, and he has mentioned that RFS runs very well over this transport. I suspect that we should definitely be able to make it work on top of the TCP/IP, even as it is now, but if if is causing the failures you've currently been experiencing then we may have some more definite test cases for areas where the networking support needs improvement. I'm quite happy to see you jumping into working on LuaRPC over TCP/IP however since I have planned to do this for some time, I just haven't had enough micros with ethernet on them that I was needing it to use with projects. > > Awaiting your response. > Raman > > > -- > View this message in context: http://elua-development.2368040.n2.nabble.com/RPC-over-SOCK-STREAM-tp6858931p6863543.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 |
|
|
rpc.socket.patch Hello, Thanks for your suggestions. I used the existing desktop socket code for LUARPC to test RPC over ethernet. I've been trying a whole lot of things to get this to work. I've been stuck. I've sent my work on this as a patch. Please look for attachment. I was able to establish a handshake between the micro and my laptop. It connects without a problem. A few things: // Test lua code from desktop require("rpc") slave, err = rpc.connect("192.168.100.90", 12346) print(slave, err) pio = slave.pio pio.pin.setdir(pio.OUTPUT, pio.PF_0) pio.pin.sethigh(pio.PF_0) // An extract: luarpc.c static void rpc_dispatch_helper( lua_State *L, ServerHandle *handle ) { struct exception e; Try { // if accepting transport is open, read function calls if ( transport_is_open( &handle->atpt ) ) { Try { switch ( transport_read_u8( &handle->atpt ) ) { case RPC_CMD_CALL: // call function transport_write_u8( &handle->atpt, RPC_READY ); /* Control reaches this point without issues. After this point, crashes */ read_cmd_call( &handle->atpt, L ); break; .... } // An extract: luarpc.c static void read_cmd_call( Transport *tpt, lua_State *L ) { int i, stackpos, good_function, nargs; u32 len; char *funcname; char *token = NULL; // read function name len = transport_read_u32( tpt ); /* function name string length */ /* Control reaches this point without issues */ funcname = ( char * )alloca( len + 1 ); transport_read_string( tpt, funcname, len ); /* Here, at this point, the code crashes. I suspect transport_read_string(###). */ funcname[ len ] = 0; // get function // @@@ perhaps handle more like variables instead of using a long string? // @@@ also strtok is not thread safe token = strtok( funcname, "." ); lua_getglobal( L, token ); token = strtok( NULL, "." ); while( token != NULL ) { lua_getfield( L, -1, token ); lua_remove( L, -2 ); token = strtok( NULL, "." ); } .... } I have modified the SConstruct file and introduced a two other boot options 'socket' and 'serial'. So, scons cpu=lm3s8962 toolchain=codesourcery boot=socket prog works fine. I've also introduced the macros ELUA_BOOT_RPC_SERIAL and ELUA_BOOT_RPC_SOCKET to do come conditional compilation. Please give me your suggestions. Please let me know how we can take the development forward. Cheers! Raman |
|
|
Hi,
On Tue, Oct 11, 2011 at 5:27 PM, raman <[hidden email]> wrote:
One thing: please hold this off a bit until I manage to push my networking layer changes into the tree, they might solve your issues (or might not, I have no idea yet :) ). This _should_ be ready this week. We'll see how we proceed afterwards.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by raman
On Tue, Oct 11, 2011 at 9:27 AM, raman <[hidden email]> wrote:
> > http://elua-development.2368040.n2.nabble.com/file/n6881171/rpc.socket.patch > rpc.socket.patch > > Hello, > > Thanks for your suggestions. I used the existing desktop socket code for > LUARPC to test RPC over > ethernet. I've been trying a whole lot of things to get this to work. I've > been stuck. I've sent my > work on this as a patch. Please look for attachment. Thanks. Plus or minus Bogdan's planned patches, I'll take a look at this to see if there's anything that stands out to me and get familiar with your implementation. I would suspect that LuaRPC should play pretty well with the uIP-based stack even with the current bugs/shortcomings given that it is somewhat cautious about spitting out lots of bytes of data until it knows it has the undivided attention of the "slave" instance. > > I was able to establish a handshake between the micro and my laptop. It > connects without a problem. > > A few things: > > // Test lua code from desktop > require("rpc") > slave, err = rpc.connect("192.168.100.90", 12346) > print(slave, err) > pio = slave.pio > pio.pin.setdir(pio.OUTPUT, pio.PF_0) > pio.pin.sethigh(pio.PF_0) I presume you're running this from a script generally and not interactively? If so/not any difference there? Also, I presume it bails on the first call (setdir)? > > // An extract: luarpc.c > static void rpc_dispatch_helper( lua_State *L, ServerHandle *handle ) > { > struct exception e; > > Try > { > // if accepting transport is open, read function calls > if ( transport_is_open( &handle->atpt ) ) > { > Try > { > switch ( transport_read_u8( &handle->atpt ) ) > { > case RPC_CMD_CALL: // call function > transport_write_u8( &handle->atpt, RPC_READY ); > /* Control reaches this point without issues. After this point, > crashes */ > read_cmd_call( &handle->atpt, L ); > break; > .... > } > > // An extract: luarpc.c > static void read_cmd_call( Transport *tpt, lua_State *L ) > { > int i, stackpos, good_function, nargs; > u32 len; > char *funcname; > char *token = NULL; > > // read function name > len = transport_read_u32( tpt ); /* function name string length */ > /* Control reaches this point without issues */ > funcname = ( char * )alloca( len + 1 ); > transport_read_string( tpt, funcname, len ); > /* Here, at this point, the code crashes. I suspect > transport_read_string(###). */ > funcname[ len ] = 0; Interesting.. Does it actually all-out crash or just hang? Depending on your platform and the type of crash we may have code for a fault handler that might spit out some characters on UART0 that might inform you of at least what type of fault occurred. If not, it's always possible to modify the fault handlers to do something a bit more useful on failure. I'd be curious if it faults, throws an exception from transport_read_buffer or something else happens... > > // get function > // @@@ perhaps handle more like variables instead of using a long string? > // @@@ also strtok is not thread safe > token = strtok( funcname, "." ); > lua_getglobal( L, token ); > token = strtok( NULL, "." ); > while( token != NULL ) > { > lua_getfield( L, -1, token ); > lua_remove( L, -2 ); > token = strtok( NULL, "." ); > } > .... > } > > I have modified the SConstruct file and introduced a two other boot options > 'socket' > and 'serial'. So, scons cpu=lm3s8962 toolchain=codesourcery boot=socket prog > works fine. I've also introduced the macros ELUA_BOOT_RPC_SERIAL and > ELUA_BOOT_RPC_SOCKET > to do come conditional compilation. OK, that sounds fine for now. We can adjust if needed later. > > Please give me your suggestions. Please let me know how we can take the > development forward. Thanks again for taking some initiative here. I'm looking forward to seeing this working and we can hopefully figure out whether the hangup is related to the RPC-side of the implementation or something going on with the TCP/IP stack. > > Cheers! > > Raman > > -- > View this message in context: http://elua-development.2368040.n2.nabble.com/RPC-over-SOCK-STREAM-tp6858931p6881171.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 |
|
|
Hello Snyder, The code crashes. It looks like it spits out a random '#####' sequence and stays in this state infinitely. I changed the code a bit to get useful info about the events on the micro during RPC before this event. I also realized I just somehow missed a transport_open() call during connect for the code on the micro (although we're only listening() here). I've added this in my branch. Please find the new patch in the attachment. rpc.sock.patch I think I also found some useful info. // An extract: luarpc.c static void read_cmd_call( Transport *tpt, lua_State *L ) { int i, stackpos, good_function, nargs; u32 len; char *funcname; char *token = NULL; // read function name len = transport_read_u32( tpt ); /* function name string length */ .... } 'len' here is an incorrect value. It looks like it reads a value which does not measure the true length of the function name. Finally, have the networking changes been pushed yet ? I can't wait for RPC over Ethernet. :) Awaiting your response. Raman |
|
|
Hi,
On Mon, Oct 17, 2011 at 2:57 PM, raman <[hidden email]> wrote:
Nope, sorry. That will have to wait a bit more. Don't hate me too much, please :) Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |