| 01:13.33 | *** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net) | |
| 01:57.41 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:22.30 | ``Erik | um, tpkg.c is a trivial libpkg client/server thingiemajigger |
| 05:33.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:43.04 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 05:43.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:00.49 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 06:00.49 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 08:44.25 | *** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net) | |
| 11:57.05 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:57.43 | dloman | Mernin all |
| 12:01.54 | starseeker | ``Erik: looked at that - but it appears to be a "the client talks, the server listens" setup |
| 12:02.21 | starseeker | dloman: did we ever get the geometry service to the point where the client and server communicate back and forth over the network? |
| 12:03.10 | dloman | starseeker: oh ya, one second |
| 12:03.17 | starseeker | based on what I've seen so far, the client and server will each have to run both a server instance, with the client sending its info to the server in order for the server to communicate back |
| 12:03.41 | starseeker | (to the client' |
| 12:03.45 | starseeker | s server) |
| 12:04.07 | dloman | ....um, no :) |
| 12:04.25 | starseeker | no? |
| 12:04.30 | starseeker | no what? :-P |
| 12:05.02 | dloman | one second, psudo afk |
| 12:05.08 | starseeker | k |
| 12:05.49 | starseeker | I've got to return some fans anyhow - if you can post how to get geomclient and geomserv to communicate meaningfully it would be a big help |
| 12:06.05 | starseeker | the C++ code is hard to follow |
| 12:07.13 | dloman | both use libNet. |
| 12:08.38 | starseeker | dloman: I'm trying to write a client that doesn't use libnet |
| 12:09.01 | dloman | already got one in progress. |
| 12:09.07 | starseeker | I can send stuff to the server, but I can't figure out how to get responses back |
| 12:09.37 | dloman | if you want, I can run u thru the code tomorrow |
| 12:09.44 | starseeker | that'd be great |
| 12:10.35 | starseeker | you're not in today, I take it? |
| 12:11.29 | dloman | not, telework |
| 12:11.59 | dloman | okay, sorry |
| 12:12.10 | dloman | was moving the laptops upstairs, hooking up, etc. |
| 12:12.18 | starseeker | that's OK |
| 12:13.29 | dloman | Okay, I am doing the java inteface thingy for ``Erik / guys upstairs |
| 12:13.35 | dloman | and am using that as a protocol validation |
| 12:13.44 | starseeker | nods |
| 12:13.45 | dloman | i have a minimal client already going in there. |
| 12:13.52 | dloman | that doesnt use libNet |
| 12:14.03 | starseeker | the bit I'm interested in right now is how you're getting responses back from the server |
| 12:14.21 | starseeker | pkg_send I figured out finally, but it seems to be a one way street so far |
| 12:20.10 | starseeker | I send the "RUALIVE" thing, but where do I look in the pkg setup for the response? |
| 12:20.43 | dloman | ...granted its a similar incarnation, java style. |
| 12:20.50 | dloman | one second. |
| 12:21.00 | dloman | lost mt Mt Dew, had to find it. Priorities ya know |
| 12:21.05 | starseeker | hehe |
| 12:21.13 | starseeker | of course - cars don't run without fuel |
| 12:21.33 | dloman | heh, well getting my 2 cyls going dunt take much :) |
| 12:21.46 | dloman | okay, |
| 12:21.47 | dloman | so |
| 12:21.53 | dloman | on the geomserv |
| 12:22.21 | dloman | we will assume that a connection has already been established and that the server side has a valid Portal to communicate thru |
| 12:23.04 | dloman | the server also will have a PortalManager that will do all the selecting on all sockets (FDs) |
| 12:23.16 | dloman | the PM has a FD<->Portal mapping. |
| 12:23.49 | dloman | when select returns a FD that is ready for read |
| 12:24.01 | dloman | a lookup on the mentioned map occurs |
| 12:24.11 | dloman | and the Portal::read() fn is called. |
| 12:24.33 | dloman | Portal::read() is simply a set of PKG calls |
| 12:24.46 | dloman | process(), suckin(), process() |
| 12:25.15 | dloman | now, the process() call will make pkg attempt to form a complete PKG msg |
| 12:25.39 | dloman | due to C++ limitations in the arena of function pointers, I had to short circuit the PKG's callback functionality |
| 12:26.15 | dloman | normally, when a pkg_conn is instantiated, it is fed a routing table |
| 12:26.44 | dloman | pkg then routes incoming pkg msgs according to the 16bit pkg_type and this routing table |
| 12:27.48 | dloman | in libNet, that routing table consists of a single type, and thus ALL pkg msgs are routed to Portal::callbackSpringboard |
| 12:27.53 | dloman | ..which is static |
| 12:28.59 | dloman | at this point, the bytes from the pkg data load are putinto a ByteArray object and the GS type is read |
| 12:29.14 | dloman | GS type is the first 16 bits of the pkg data load. |
| 12:29.18 | starseeker | ok, I think I'm with you |
| 12:29.43 | starseeker | it then deserializes the message and figures out what it's dealing with |
| 12:29.58 | dloman | the GSType is used in the NetMsg Factory to figure out which NetMsg deserial cstr to call. |
| 12:30.03 | dloman | exactly. |
| 12:30.24 | dloman | after a successful deserial, the NetMsg Factory hands the completed message over to the NetMsgRouter |
| 12:30.49 | dloman | NetMsgRouter is (right now) a simple subscriber/publisher setup |
| 12:31.56 | dloman | so if there is no routing data for a GS NetMsg, then it's discarded |
| 12:32.12 | dloman | looking at GeometryService::registerMsgRoutes, |
| 12:32.17 | starseeker | ok... where would it get routing data? |
| 12:32.33 | dloman | i see there is no mapping (currently) for RUALIVE |
| 12:32.59 | CIA-14 | BRL-CAD: 03starseeker * r43858 10/geomcore/trunk/src/GS/CMakeLists.txt: Whoops, copy paste typo |
| 12:33.35 | dloman | hrm, there are two netmsg types that are supposed to be handled by the Portal object, RemNodeNameSet and RUALIVE |
| 12:33.46 | dloman | i wonder why its not working... |
| 12:34.03 | dloman | i am debugging the gs with all the changes still, might be something there. |
| 12:34.09 | starseeker | k |
| 12:34.18 | starseeker | was going insane on Sunday |
| 12:34.36 | dloman | but to answer your 'where does it get routing data from ' question: its all configurable. |
| 12:34.56 | dloman | the geomserve does it in GeometryService.cxx line 58 |
| 12:35.21 | starseeker | dloman: as an aside, it sounds like we're paying a fairly high complexity price for being able to use C++ |
| 12:35.52 | dloman | eh, kinda. |
| 12:36.09 | starseeker | not a criticism, just curious - how come C++ instead of C? |
| 12:36.14 | dloman | the pkg complexity has been minimized (with lots of hairpulling and pain) |
| 12:36.28 | starseeker | right, but why not just do it the libpkg way in C? |
| 12:36.34 | dloman | from what I understand, its from a few differnt sources. |
| 12:37.02 | dloman | desire to have a C++ interface for the general public |
| 12:37.22 | dloman | C++ lends itself to a plugin-able style app arch better than C |
| 12:37.27 | dloman | and a few others i've forgotten. |
| 12:37.31 | starseeker | urm. For the GS, that's kinda moot - the interface is the network protocol |
| 12:37.44 | dloman | ping brlcad, im sure he remembers all the reasons :) |
| 12:37.55 | dloman | not really. |
| 12:38.14 | dloman | the design for the GS is to have modules of functionality that can be 'plugged in' |
| 12:38.27 | dloman | aka, the STEPConverter plugin |
| 12:38.32 | starseeker | uh... that's on the backend |
| 12:38.46 | dloman | yeah |
| 12:39.35 | starseeker | dloman: ok, well I've got to get those fans back - if you can debug why RUALIVE isn't doing anything I'd appreciate it :-) |
| 12:39.44 | dloman | kk |
| 12:39.50 | starseeker | thanks, bbl |
| 12:47.19 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 12:47.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:33.57 | ``Erik | hm, the build stuff I added was just copying another file and updating it... BSD license is dandy with me *shrug* (I think that technically, my contributions are considered public domain) |
| 13:44.23 | dloman | ``Erik: segfaulting in your magic endian converter in geomcore |
| 13:45.10 | dloman | the whole dat[0] ^= data[7] ^= data[0] ^= data[7] block |
| 13:47.48 | dloman | need a little help there since i verified the data its manipulating is not NULL, but all those bitwise ops are beyond me :/ |
| 13:48.21 | ``Erik | hmmmm |
| 14:07.06 | CIA-14 | BRL-CAD: 03erikgreenwald * r43859 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: use ntohll instead of the xor hack |
| 14:12.50 | dloman | excellent, thanks! |
| 14:13.02 | ``Erik | that fixed it? O.o |
| 14:13.30 | dloman | well, i had to put the htohll call down in the _serialize() fn too, but yeah, it seems to be working |
| 14:13.36 | dloman | well, it doesnt segfault anymore |
| 14:13.47 | dloman | im going to validate the values in a second |
| 14:13.56 | ``Erik | cool |
| 14:14.24 | ``Erik | http://www.cnn.com/2011/POLITICS/03/13/crowley.stepping.down/index.html?hpt=T2 |
| 14:54.37 | starseeker | dloman: is there a client/server setup anywhere (test app, whatever) that I can start up a server and client, type "ping" in the client and have the *client* (not the server) print out the server's *PONG* response? |
| 14:55.10 | starseeker | i.e. not a log message being generated by the server, but a command line report in the client of what the server's response was? |
| 14:57.49 | dloman | yes, Im debugging that very thing atm |
| 14:58.32 | starseeker | cool, thanks |
| 14:59.04 | starseeker | feels another hair turn grey... |
| 14:59.29 | dloman | hows the basement dewatering going? |
| 14:59.57 | starseeker | we're pretty much dried out - the test now is to see what will happen with the pump actually in place |
| 15:00.16 | dloman | did you do an op test of the pump? |
| 15:00.40 | starseeker | heh - that's what finally stopped the flooding from getting worse Thursday |
| 15:00.47 | starseeker | pump was working for a while to clear the backlog |
| 15:01.04 | dloman | well, nothing like a burn in :) |
| 15:01.11 | dloman | good to hear you are all dried out. |
| 15:01.27 | dloman | sucky thing to be happening in a 'new' home :/ |
| 15:01.46 | starseeker | no kidding - we're probably looking a this, roof and gutters this spring |
| 15:11.06 | dloman | he he, neat. somehow, my PING messages are all originating from the same time... a long time ago, resulting in roundtrip times in the 3 million seconds range, lol |
| 16:03.00 | dloman | is htonll a libbu thing? |
| 16:03.13 | starseeker | I don't believe so |
| 16:03.47 | dloman | i cant find info on htonll.... htonl, sure but not the ll version |
| 16:03.59 | starseeker | http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/htonll.htm |
| 16:04.35 | dloman | bah, bloody google was replacing text for me :/ |
| 16:04.55 | starseeker | also, see bu.h line 661 or thereabouts |
| 16:04.56 | dloman | thanks :) |
| 16:05.06 | starseeker | not all platforms have it |
| 16:05.11 | starseeker | (apparently) |
| 17:21.21 | CIA-14 | BRL-CAD: 03davidloman * r43860 10/geomcore/trunk/src/GS/GSClient.cxx: Clean up PING and PONG logging. |
| 17:22.34 | CIA-14 | BRL-CAD: 03davidloman * r43861 10/geomcore/trunk/src/GS/GeometryService.cxx: Clean up PING and PONG logging on server side also. |
| 17:25.22 | CIA-14 | BRL-CAD: 03davidloman * r43862 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: Fix a network/host ordering issue. |
| 17:38.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.246) | |
| 17:38.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:55.28 | starseeker | gets back to basics: http://beej.us/guide/bgnet/output/html/multipage/index.html |
| 20:15.22 | ``Erik | http://bravenewclimate.com/2011/03/13/fukushima-simple-explanation/ |
| 20:38.03 | ``Erik | starseeker: ISC license (like the new BSD), specifically for the mdoc macro package, http://mdocml.bsd.lv/ |
| 20:47.54 | starseeker | awesome |
| 20:49.45 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 21:01.08 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 22:01.23 | Ralith | why do we need a new BSD? |
| 22:02.07 | starseeker | Ralith: new BSD license (a.k.a Modified BSD license) - no advertising clause |
| 22:02.39 | Ralith | oh, so the "new BSD", not the new "BSD" |
| 22:04.41 | starseeker | right |