[Setup-tool-hackers] bacon-message-connection (was Re: ShippingVera with 2.4)
- From: Bastien Nocera <hadess hadess net>
- To: Michael Meeks <michael ximian com>
- Cc: Havoc Pennington <hp redhat com>, GNOME Desktop Hackers <desktop-devel-list gnome org>, GST <setup-tool-hackers ximian com>
- Subject: [Setup-tool-hackers] bacon-message-connection (was Re: ShippingVera with 2.4)
- Date: 27 Feb 2003 18:08:10 +0000
On Thu, 2003-02-27 at 14:51, Michael Meeks wrote:
> Hi Bastien,
>
> On Thu, 2003-02-27 at 14:14, Bastien Nocera wrote:
> > > It's very hard to compare a system that exists, and works
> > > with one that does not.
> >
> > I've also got my very own thingo to do simple IPC, that I use in totem:
> > $ cat bacon-message-connection.[ch] | wc -l
> > 271
> >
> > And that replaces the whole of CORBA for simple IPC purposes.
>
> Well yes it's small. The facts that again it's a type-unsafe, "send
> string" API, with no way of ascertaining what the interfaces are, are
> rather unfavourable.
It's simple, and only sends strings. The server is an existing instance
of the application. That's why the protocol is so simple.
There are also a lot of your comments that would really need to be taken
into account if this was a communication protocol used remotely. It is
local only, thus the risk of errors is minimised.
> There are also the following bugs/mis-features I saw with a brief
> glance, correct me if I'm wrong:
>
> * missing syscall error handling
I check the return values of all the syscalls. What did I miss exactly?
> * blocking accept
No, it's in a different loop, thanks to the usage of GIOChannel.
> * not handling EINTR
See Havoc's mail
> * assuming non-blocking / short reads [ possibly in-spec,
> perhaps better to use NON_BLOCK ].
It is assumed that short reads are enough.
> * blocking connection write
Usually the client's only purpose is to send messages to the server
(already running instance) and exit. So it is appropriate.
> * no error checking / short write handling on write
That needs fixing.
> * server_cb locks in a tight loop on 'read' error
That needs a test for EIO which is the only error that could really
happen in this case.
> * looks like it creates an insecure, world writable /tmp
> Unix domain socket -> instant, huge security hazard
As I said, it's user writable only. I'm not *that* stupid.
> * doesn't do collision checking => instant DOS attack.
If the user wants to DOS his own application, well, that's his right. He
could also load a 500 megs TIFF image in the GIMP and lock his machine
up. That's his problem.
Thank you for the comments.
Cheers
--
/Bastien Nocera
http://hadess.net
#2 0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault
_______________________________________________
setup-tool-hackers maillist - setup-tool-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]