Isaac Dunham <ibid...@gmail.com> writes: > On Sat, Nov 14, 2015 at 07:36:08PM +0000, Rainer Weikusat wrote:
[...] >> OO RPC system intended to enable long-running >> applications to call methods implemented by other long-running >> applications provided these other long-running applications run on the >> same computer. > <snip> > > Your explanation is pretty good. > But there are a very few more details that I thought should be mentioned: > > - Regarding 'long-running', it seems worthwhile to mention that D-Bus > is the main *stateful* IPC protocol available. > In other words, it is designed around the concept that you're dealing with > programs that will not be restarted. > This, apparently, makes it simpler to use, since rather than dealing with > failures of the 'remote' process, you can simply ignore them because it's > irrecoverable anyhow. s/irrecoverable anyhow/just a problem for users, so fuck it/ [...] > - Regarding 'on the same computer', it's apparently supposed to be > 'possible' to set up some method of forwarding over ssh. > I saw references to this being already implemented in one of the threads > Miroslav posted in; but as far as documentation goes, I see only a > two and a half year old page mentioning it as a possible but untested > solution. It's obviously possible to relay between AF_UNIX and AF_INET stream sockets, eg, I have a C program here (944 LOC) dedicated to doing just (and do it fast) I wrote in order to connect two computers to the same instance (and thus, URL database) of a web content classification program but this really only works when the server is stateless because the relaying program can then transparently reconnect to it. It also doesn't turn a protocol designed to work by block memory copies into one which will work sensibly/ efficiently over TCP, especially when latency start to become measurable (eg, the RTT between Europe and the USA is ca 0.1s), segments are getting lost or there's only little effective bandwidth available. And then, of course (I take your word for that), the fantasy that programs are started on boot and keep running until the heat death of the universe becomes absoluty untenable once more than one computer is involved. And then, of course, simple forwarders provide neither authentication nor integrity protection nor content confidentiality. It's possible to work around that by using a real VPN ($person has a clue) or tunneling over ssh ($person is on a "baffle them with bullshit" mission) but that's the point where the "workaround" starts to become more complicated to maintain than the facility itself. Lastly "everybody's darling is nobody's friend" (I'm afraid but I have to quote myself here): A protocol which is design to be usable in any conceivable situation will be an awkward choice for most actual situations. I implemented a system for forwarding SNMP (v2 of course) securely over the internet and query/ control printers speaking SNMP over USB in the past. A D-BUS<->ASN.1 bridge would neatly fit into this and take the pleasing impenetrability of the system to a whole new level. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng