randy@erik.UUCP (Randy Brown) (10/26/90)
Last June there was a brief exchange on the question of using an X client as an RPC server. I saved the bit below, which I am reposting to forestall the inevitable requests. I am interested to know if anyone has further experience, particularly with a solution based on Xt rather than Xview. ... Randy Brown (uunet!erik!rbrown) from Don Bennett <dpb@frame.com> (408)433-3311 Frame Technology > rpcListen(client_data, source, id) > caddr_t client_data; > int *source; > XtInputId *id; > { > svc_getreq(1 << *source); > } > > main() > { > int fd; > > svc_register(transp, ...); > fd = transp->xp_sock; > XtAppAddInput(_XtDefaultAppContext(), fd, XtInputReadMask, rpcListen, 0); > XtMainLoop(); > } from David Brownell <db@east.sun.com> (508) 671-0348 > It's worth noting that this posted solution works only for UDP RPCs. > That is, if you use TCP for simpler semantics, more data than the > default of 8 Kbytes, or better error reporting, this doesn't work. > > Also, this uses the obsolete svc_getreq() call, which is limited > to 32 file descriptors. More recent UNIXes have a much higher > limit -- this should use svc_getreqset() instead, which handles > many more file descriptors. > > The issue with TCP is that the RPC library needs to allocate and > deallocate file descriptors dynamically. To handle this within > Xt, the input callback for the tcp-based SVCXPRT must diff the RPC > file descriptors in svc_fdset before and after it calls svc_getreqset(), > invoking XtAppAddInput (or XtAddInput) on new file descriptors and > calling XtRemoveInput() one ones that've disappeared. > > The upcoming release of XView will do this for you automatically if > you ask, so that you won't have to scour the innards of the window > system and notifier documentation to find out how to do this!
db@witzend.East.Sun.COM (David Brownell) (10/26/90)
In article <9010252039.AA04627@erik.uucp> randy@erik.UUCP (Randy Brown) writes: > Last June there was a brief exchange on the question of using an X > client as an RPC server. I saved the bit below, which I am reposting ... > from David Brownell <db@east.sun.com> (508) 671-0348 > > The upcoming release of XView will do this for you automatically if > > you ask, so that you won't have to scour the innards of the window > > system and notifier documentation to find out how to do this! Or the RPC documentation, for that matter! It's now available, both in the version of XView that's available from MIT and in Open Windows version 2. Call notify_enable_rpc_svc(TRUE) to make the XView notifier do the RPC svc_run() dispatching in addition to all the other dispatching it does. The best way to use this is as follows. The only step specific to the XView toolkit is the details of educating the window system toolkit about the RPC subsystem. The basic trick is to use the X server as the rendezvous, rather than the portmapper on some host. - Create the SVCXPRT handle via svc{udp,tcp}_create() and svc_register() it. - Get the address of socket being used (xprt->xp_sock) using getsockname(). - Stick the host address and port number in some X window property (paying attention to byte order) so the other process will be able to see it. - Educate the window toolkit about the RPC subsystem. - If using TCP, both client and server should ignore SIGPIPE so they don't get nuked when some host or network somewhere goes away. Sometime I'll have to dust off that proposal for a TCP_PORT atom, so people don't need to define their own property types all the time. Also, if you're using the transport independent RPC (SVR4) the details of transport level addressing are different; sockets aren't used. - Dave One of the Million monkeys ... see, here's my keyboard!