On Thu, Jul 10, 2014 at 01:19:44PM +0200, Gustav Fransson Nyvell wrote:
> On 07/10/14 12:39, Otto Moerbeek wrote:
> >On Thu, Jul 10, 2014 at 12:20:24PM +0200, Gustav Fransson Nyvell wrote:
> >
> >>msgrcv(2), msgsnd(2) does exactly this. They're even syscalls. Maybe not as
> >>toyable as a sqlite database backend but surely faster better etc. Does
> >>anyone use them?
> >>
> >>--
> >>This e-mail is confidential and may not be shared with anyone other than
> >>recipient(s) without written permission from sender.
> >the msg* api is cursed by it's SysV descend.
> >
> >But as the OP never mentioned what his requiremenst are (guaranteed
> >delivery?, in-order?, duplicate avoidance?, hardware failure
> >resistance?, multi-platform?, authenticated src and dst?), any comment
> >is futile.
> >
> > -Otto
> >
> >
> >
> Hi,
>
> Oh, let me begin by saying I have some connections in AT&T, which seem to be
> behind msg*. Even though they might hate me at the moment.
>
> I think that libmessage as it works now is pretty much msg* 2.0 because it
> can handle any length queueid and length message. My requirements or target
> is one message sent, one message read. Order no guaranteed. Basically like
> your mailbox at home or whereever you live. You get an envelope, you can
> only open it once. Haha, okay, it doesn't evaporate, these messages do.
> You'll have to keep a copy. Guaranteed delivery is #1 priority, nothing can
> be lost... There's no authentication in libmessage but a lot in msg*. I'm
> kind of torn about this. Having open messaging is quite good and if you need
> secrecy - encrypt. Like the internet. Because it's a fail-safe. I'm sort of
> aiming for the "business" transaction "market" where you have something like
> "Joe wants 2 beers" and that message is sent to a queue and someone finds it
> and goes to get beers for Joe. You know the deal. It's what MQs do, except
> MQs usually suck, hard. Anyway, I'm not expecting wide adoption of
> libmessage, but I wanted to ask you, how do you handle something like /tmp
> which has 777 permissions. Isn't that extremely unsafe? Someone could just
> rm it and all hell would break loose. (I haven't run a shell service so this
> has never happened to me.) Why is it 777? Shouldn't someone look at this...?
> :)
You gotta pay attention, it's 1777 (note the t bit).
-Otto
