19 May 2012 11:25
Re: Proposal: Add option to add dates to write(1)
Matthew Mondor <mm_lists <at> pulsar-zone.net>
2012-05-19 09:25:51 GMT
2012-05-19 09:25:51 GMT
On Sat, 19 May 2012 04:11:58 -0400 (EDT) Mouse <mouse <at> Rodents-Montreal.ORG> wrote: > > If datagrams are used, the daemon design would be very simple, simply > > handling one message at a time arriving on a single descriptor. I no > > longer remember if only connected stream sockets receive client > > credentials, [...] > > I'd suggest considering doing a datagram send for initial rendezvous > and to get SCM_CREDS, but accompany that datagram send with an > SCM_RIGHTS send of one end of a SOCK_STREAM socketpair over which all > further communication would be carried out (or perhaps two fds, one > each way, allowing the user of pipes instead of a socketpair). > > This would, it seems to me, give the best of both worlds. I know that user credentials can be obtained on SOCK_STREAM connected sockets already, so if using these, datagrams would not be required. It's for SOCK_DGRAM that I don't remember if we can obtain them on a per-datagram basis (I could check this Sunday probably), but if so, apart from the line length limit, I think that this would offer the simplest daemon implementation (no need to deal much with multiple client descriptors, partial writes/buffering, connection state, FD event to connection object index/pointer, gracefully handling socket|I/O errors, etc.) The pipes idea seems interesting for bidirectional communication, but since the data is traditionally simply written to the destination user's tty, I wonder if this is wanted... I didn't think of it initially, but the daemon design would also allow sending messages to remote systems as an extension if that was eventually wanted. Remote hosts would need the daemon to listen on the network as well and be configured with the set of public keys of the allowed sending peers, which is probably similar to what the new syslogd code does. However, I'm not sure I want to implement this, at least not initially, as I personally don't need this "overkill" feature, (I already use an SSL-enabled IRCd, and we have SSH which could invoke write(1) remotely :)... -- -- Matt
RSS Feed