Re: Proposal: Add option to add dates to write(1)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sat, 19 May 2012 04:11:58 -0400 (EDT)
Mouse <mouse%Rodents-Montreal.ORG@localhost> 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