Darin Fisher Reporter
	Description • 22 years ago

provide IPC mechanism for profile sharing, etc.

the requirement in a nutshell is to provide an out-of-process daemon and
messaging system.  client applications can connect to the daemon and send
messages to particular "daemon modules" identified by UUID.  daemon modules can
send messages to any client connected to the daemon.  clients may have several
message handlers, each identified by UUID.  hence, messages from the client
contain the UUID of the target module, and messages from the module contain the
UUID of the target message handler for a given client.

the daemon must support plug-in modules.  this requirement is meant to allow PSM
the option to implement a module that would host a shared cert database, for
example.

the daemon can also provide a mechanism for client discovery.  this may be
accomplished by allowing clients to register themselves under common names.  the
daemon can then be used "like a DNS server" to resolve a name like "browser"
into the client ID (the "address") of the client registered under that name.

the daemon can then also provide a simple mechanism for forwarding messages from
one client to another.  for example, a "browser" app might request something
from the "addressbook" app and vice versa.  this forwarding mechanism also makes
possible a form of d-xpcom (which dougt has prototyped).

lastly, this IPC mechanism should not get in the way of mozilla doing its normal
thing.  if the IPC mechanism should fail for whatever reason, it must not bring
down the rest of mozilla! ;-)

so, i've been developing this "patch" on the trunk under modules/ipc (not pulled
by default), but the plan is ultimately to move it out of modules/ since that is
a deprecated part of the tree.  mozilla/ipc may become its new home.

please check out the code in modules/ipc, and let me know what you think.

	Darin Fisher Reporter
	Comment 1 • 22 years ago

oh, i forgot to mention: i've tested the code under rh7.3, rh8.0, win2k, and
osx10.1.5 (mach-o).  the windows impl uses WM_COPYDATA messages, and the others
use TCP/UNIX sockets (leveraging necko heavily).  the windows impl introduces a
new thread for the hidden window's message pump (in order to not block the main
thread when sending/receiving messages).

	Jaime Rodriguez, Jr.
	Comment 2 • 22 years ago

Marking as topembed+ per EDT triage, as this is needed for GRE, and desired by a
major embedding customer.

	Doug Turner (:dougt)
	Comment 3 • 22 years ago

looks fine.  r=dougt.

	timeless
	Comment 4 • 22 years ago

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/build/Makefile.in&rev=1.2&mark=49,50,53#45
i don't think a module should ever need to require itself.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/build/ipcCID.h&rev=1.1&mark=44#41
here's a quick survey:
[timeless@viper mozilla-1.3a]$ ./run-mozilla.sh ./xpcshell
js> const C=Components.classes,I=Components.interfaces;
js> b=0; for (a in C) if (/\/service/.test(a)) ++b;
6
js> b=0; for (a in C) if (/-service/.test(a)) ++b;
39
js> b=0; for (a in C) if (/[^-\/]service/.test(a)) ++b;
30
- is the most common, / is very rare. (no delim is more common.) please use -.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/build/ipcModule.cpp&rev=1.5&mark=52,85,101,102,104-105
please either remove the code or make it so that it could be consistently
flipped on, right now changing from #if 0 to #if 1 and then removing the /* and
*/ would result in compile errors. At the very least remove the /**/ notation.

as directories go, /common/ doesn't match *any* convention present in the
mozilla tree.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcConfig.h&rev=1.8&mark=72#68
is this absolutely safe? what happens if user timely creates /tmp/.mozilla-ipc
and then user timeless tries to use a mozilla-ipc app? can timely prevent
timeless's app from working or otherwise interfere?

Is there any serious documentation which explains why these classes exist as
they do? I'd like to know why we need the string classes you're creating, we
already have a bunch of datastructures in xpcom including a deque, some arrays
with deletion/insertion capabilities.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcStringList.h&rev=1.3&mark=64#62
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcMessage.h&rev=1.4&mark=177#176
that's a great comment, could someone please flesh it out?

http://lxr.mozilla.org/mozilla/source/modules/ipc/common/ipcLog.cpp
there's no os/2 impl (mkaply), and there's no macos impl, and who else did you
miss? please give those people a heads up before you break them.

sys/types.h, are you sure there isn't a configure test that looks for this? (cls)
> do any of these files ever live in interesting places:
> sys/types.h, sys/stat.h, unistd.h, fnctl.h, signal.h?
<cls> sometimes they don't exist at all
<cls> fcntl.h & signal.h in particular (and sometimes you want sys/signal.h)

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcMessage.h&rev=1.4&mark=114-115#112
I don't think you mean what you wrote. I think 'only' should be dropped.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcMessagePrimitives.cpp&rev=1.2&mark=45#40
should this be PRInt32?

unsigned int + 2 > max unsigned int 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcIDList.cpp&rev=1.1&mark=48,54,61
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcList.h&rev=1.2&mark=61-62,82,162,169
<and many others>
don't use NULL. use nsnull or 0.

ipcMessage::Clone() and ipcMessage::ipcMessage(const ipcMessage&)
1. you don't declare the later illegal which means someone could mess up and use it.
2. Clone isn't virtual, so why not just change Clone() to be a copy constructor
and do things that way?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcList.h&rev=1.2&mark=66-68,77-79,91-93,102-104,111-113,124-126,136-138,148-150
<and many others>
please use doxygen friendly /**\n * comments\n */

please use doxygen friendly @param and @return and ...

 52 // XXX ipcMessageCast is probably not the best name for this class.
hrm, this class looks like syntactic sugar. 

IPCM_MSG_TYPE_CLIENT_DEL_TARGET
there's no documentation for this.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcm.h&rev=1.9&mark=270,254,272
there are typos/minor errors in the documentation

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/Makefile.in&rev=1.7&mark=56,58-59#55
this doesn't scale nicely for OS/2 and Mac ...

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/Makefile.in&rev=1.7&mark=78#75
why don't you link against the version in common?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/ipcCommandModule.cpp&rev=1.18&mark=68,74,75#59
your calloc could be a malloc w/ a null assignment for str[count] on line 75

http://lxr.mozilla.org/mozilla/source/modules/ipc/daemon/ipcModule.h
should struct ipcDaemonMethods be extern C? ah, it can't be. the only change
required would be from nsID& to nsID*.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/ipcModuleReg.h&rev=1.6&mark=44-45#43
so, if i call IPC_InitModuleReg, IPC_ShutdownModuleReg, IPC_InitModuleReg,
IPC_ShutdownModuleReg, then i can't call IPC_InitModuleReg again? :)

If you want to allow that next call, then something like this would work:
IPC_InitModuleReg can not be called more than once before calling
IPC_ShutdownModuleReg.

http://lxr.mozilla.org/mozilla/source/modules/ipc/daemon/ipcModuleUtil.h
<and others>
Don't use PR_ASSERT. you require XPCOM, so use NS_ASSERTION.

 64 PRStatus
 65 IPC_SendMsg(ipcClient *client, ipcMessage *msg)
 75         delete msg;
This transfer of ownership worries me, it is documented, but i don't think it's
a good idea. is there some real benefit to capturing ownership on success? why
not always leave it to the caller?

104     // we use fcntl for locking.  assumption: filesystem should be local.
you can't make these assumptions. and again /tmp seems evil.

123     // write our PID into the lock file (this just seems like a good idea...
124     // no real purpose otherwise).
instead of reinventing locking, why don't you use the profile lock code? it
should live in xpcom, if it doesn't then you can file a bug and get that fixed.

http://lxr.mozilla.org/mozilla/source/modules/ipc/daemon/ipcdUnix.cpp
402     listenFD = PR_OpenTCPSocket(PR_AF_LOCAL);
403     if (!listenFD) {
404         LOG(("PR_OpenUDPSocket failed [%d]\n", PR_GetError()));
right... fix the message :)

i was pretty sure that we wanted files to have modelines to help editors out.
the file i'm looking at doesn't ...

There once was a generic ban on adding templates randomly.  you've added this
stringlist template which imo could have been handled by a simple base class.  
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcList.h&rev=1.2&mark=47-51
is a contract which your template doesn't actually enforce but which could
_easily_ have been enforced by a baseclass.

Please have scc or someone take a _serious_ look at this module before you land
it somewhere proper.

more later.
--
concerns, what prevents user timely from sending data to a mozilla-ipc process
timeless is running? (w32, unix)

as for directory names, mozilla/geckoipc seems reasonable, and something can be
done like this for the contracts too. this ipc is designed for ipc w/in mozilla
clients not ipc w/ the rest of the os, and i'd like to reserve
@mozilla.org/ipc-* for that. 

	timeless
	Comment 6 • 22 years ago

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcService.cpp&rev=1.18&mark=202,366,378#179

the callee will complain about null. in almost all other instances you avoid
calling it w/ null.

in the second instance you could and probably should return outofmemory

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcService.cpp&rev=1.18&mark=297-299,323-325,#296
you crash if the query creation fails


http://lxr.mozilla.org/mozilla/source/modules/ipc/src/ipcSocketProviderUnix.cpp&rev=1.4&mark=42#41
traditionally nspr yells and screams when people use nspr private methods... (wtc)

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransport.cpp&rev=1.13&mark=190-192#189
you could be nice to the processor and skip the math and compare
mConnectionAttemptCount with 6 instead of ms w/ 1000

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransport.h&rev=1.9&mark=71,75#68
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransport.cpp&rev=1.13&mark=205#204
This looks like NS_IMPL_THREADSAFE_ISUPPORTS1 to me...

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransportUnix.cpp&rev=1.8&mark=145,146#135
the sent hello assignment is optimistic and will be incorrect if the new fails.

theoretical nit, a box could run ipv6 w/o ipv4. or someone could be using
browser+mail w/o any version of ip...

minor perf warning, PR_GetEnv can be expensive on some platforms, and since its
value shouldn't change you might want to consider caching it (static)

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransportWin.cpp&rev=1.9&mark=123,126
you crash if new fails

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransportWin.cpp&rev=1.9&mark=263
you aren't supposed to do explicit comparisons w/ PRBools. use if (foo) or if (!foo)

-- more later, i'm catching a bus to toledo and then i'm traveling until  late
tomorrow. i'll get the last dirs next week. (i skimmed your responses just now
but am out of time)

	Darin Fisher Reporter
	Comment 8 • 22 years ago

nevermind my comment about using a randomly generated directory in /tmp... other
processes need to be able to locate the directory, so it must have a well known
location.

	benc
	Comment 9 • 22 years ago

Darin: will there be steps I can use to verify this when it is implemented, or
should I get an API tester for this bug?

	Darin Fisher Reporter
	Comment 10 • 22 years ago

it might be good to have an API tester look at this.  there won't be any
application to test (other than the TestIPC application).

	Darin Fisher Reporter
	Comment 11 • 22 years ago

1.4 is the big embedding milestone.  hoping to finalize the ipc module by 1.4 alpha.

	Darin Fisher Reporter
	Comment 12 • 22 years ago

you'll need to set MOZ_IPC=1 as an environment variable before building.

	Darin Fisher Reporter
	Comment 13 • 22 years ago

latest bits now reside on the branch "IPC_BRANCH_20030304" and live under
mozilla/ipc/ipcd/.  this directory structure was approved by brendan.  there's
now an extensions directory that currently just contains a lock service.  we
will be adding the transaction manager component as an extension.

	Sergei Dolgov
	Comment 15 • 22 years ago

it seems we need special implementation if it for BeOS or disabling all related
things by default.
Maybe it should be based on BMessages, not on sockets

	saari (gone)
	Comment 16 • 22 years ago

should this be marked fixed now?

	Darin Fisher Reporter
	Comment 17 • 22 years ago

saari: no, because i still need to work in brendan's review comments and
finally, i need to land the IPC service on the trunk.  it currently just lives
on a branch, and that is what the trunk is pulling.  i'd like to keep this bug
open to finish up the nitty gritty.

	Colin Blake
	Comment 18 • 22 years ago

I need to figure out what to do on OpenVMS. We don't have local (UNIX domain)
sockets. If I need to replace the use of local sockets with something else, what
is the set of routines I need to implement?

	Darin Fisher Reporter
	Comment 19 • 22 years ago

colin: you would need to implement ipcTransport for VMS.  please see
ipcTransportUnix and ipcTransportWin for examples.  in the meantime, we should
probably disable profilesharing for VMS builds.

	Conrad Carlen (not reading bugmail)
	Comment 20 • 22 years ago

Disabling it in configure.in for VMS, along with the platforms without
implementations, would probably be bug 204177.

	Roland Mainz
	Comment 21 • 22 years ago

Colin Blake wrote:
> I need to figure out what to do on OpenVMS. We don't have local (UNIX domain)
> sockets. If I need to replace the use of local sockets with something else, 
> what is the set of routines I need to implement?

Maybe the best solution would be to use libICE (which should be preferred on X11
platforms in general over the home-grown code which is currently be used for
Mozilla IPC) ...

	Colin Blake
	Comment 22 • 22 years ago

Is there any interest in an ICE solution for X11 platforms? Or should I just
make the existing UNIX code use regular sockets for OpenVMS (daemon could write
address and port into the lock file, clients can connect using the information
they read from the lock file)?

	Christopher Blizzard (:blizzard)
	Comment 23 • 22 years ago

Ugh.  ICE.

	Darin Fisher Reporter
	Comment 24 • 22 years ago

colin: that sounds like a great plan.  the only issue is that be sure to verify
that the existing ownership checks on the lock file are kept in place.  it is
crucial that the lock file be owned by the user and be accessible only be the
user.  of course, i think you still would have a security hole if someone were
doing port scanning.  the problem being that any process owned by any user could
technically connect to the TCP port.  you could of course limit access to only
those users with a local account, but that doesn't prevent the port scanning
exploit.  basically, this is the reason why i didn't just use TCP/IP under windows.

	Mark Kaplun
	Comment 25 • 22 years ago

Sorry for jumping uninvited and without looking at the code, but if the windows
implementation is using the WM_COPYDATA, then there might be a problem when
using the IPC with the windows XP fast user switching feature.

When fast user switcing is used FindWindow can not find the mozilla window only
which was opened for another user. This will imply that a deamon will be run for
each user, which is not what I think of as a deamon.

IMHO a better implementation for XP will be to use named pipes.

	Colin Blake
	Comment 26 • 22 years ago

re: comment 24
To prevent port scanning the daemon could write a random number along with the
address and port into the lock file. Then when a client connects it has to first
send the random number, and if the daemon doesn't receive this, then it
disconnects. As long as the lock file is owned by the correct user and protected
accordingly, only that user will be able to successfully communicate with the
daemon. Getting a little kludgy, isn't it. I wish OpenVMS has named pipes. We do
have other IPC mechanisms on OpenVMS, but I was hoping to get by with as little
change as possible.

	Darin Fisher Reporter
	Comment 27 • 22 years ago

colin: yeah, that sounds like it would basically work.

	Darin Fisher Reporter
	Comment 28 • 22 years ago

Mark: there is meant to be exactly one daemon per user.  this corresponds nicely
with the fact that the user's mozilla profile is typically stored under
"Documents And Settings\%USERNAME%\Application Data\Mozilla\..."

	Colin Blake
	Comment 29 • 21 years ago

I need to understand profile sharing a little better than I currently do. Darin,
over in bug 205765 you say:

"My assumption was that profile sharing would simply not be a feature available
on the ports until sometime later.  Anyways, it will not be used by Mozilla
until some distant milestone.  As is, it is just a feature of the GRE that may
find a home in some embedding applications in the future."

I thought the current plan was to break "Mozilla the suite" into "Mozilla the
components" in 1.5. And when that happens, if I want to run Moz Mail and Moz
Browser together then won't I NEED profile sharing? This hardly makes profile
sharing a feature that can wait "until sometime later".

Or am I misunderstanding what profile sharing is and how it will be used?

	Colin Blake
	Comment 30 • 21 years ago

Darin, is comment 26 something that some other (currently without a profile
sharing solution) platforms could use? Everyone has IP sockets and files, right?
Could it be generic enough to be the default implementation for platforms which
don't have something better? If so, is this something you could code up quickly?
You could certainly do it a lot quicker than me!

	Darin Fisher Reporter
	Comment 31 • 21 years ago

colin:

so, actually a lot of things about mozilla 1.5 remain up in the air.  as i
understand it, browser and mail could end up being completely separate apps with
completely separate profiles (in the beginning).  this is the state of things
today.  we've been thinking that profile sharing would be important for those
two apps since it would enable sharing of wallet data, certs, and other things
that may be important to both mail and browser.  but, for the most part, it is
possible for 1.5 to not use profile sharing.  of course, there will be loss of
usability relative to 1.4, but that might be a reasonable tradeoff given the
complexity of the transition.  also, 1.5 is going to be a longer than usual
development cycle because of all the scary changes happening.  so, i think i'm
correct in saying that there isn't a huge hurry at the moment to finish off the
IPC service cross-platform.  that said, it is of course a good thing that we get
started sooner than later ;-)

so, as for your thoughts about a general purpose local-TCP/IP solution... i
think that that is probably the right way to go as a third IPC mechanism that
ports may choose to utilize.  like i suspect BeOS probably supports named
pipes.. in which case, it can probably share the XP_UNIX impl.  so, maybe VMS
will be the only platform using this TCP/IP solution.  i'm busy w/ 1.4 final
stuff right now and have a vacation coming up shortly... so maybe we should hash
something out soon.  do you want to take a stab at a patch or i can try to whip
something up for you to test?

	Colin Blake
	Comment 32 • 21 years ago

Darin, its good to hear that profile sharing isn't going to be mandatory (if you
want a good experience) in 1.5. However, as you said, its better to get started
on a solution for OpenVMS sooner rather than later.

Changing the sockets to be INET instead of LOCAL doesn't seem too difficult, the
part that I'm not so sure about is sending/receiving the randon number which
prevents someone from port scanning. If you could give me some pointers as to
where in the code would be best to handle that, it would help a lot.

Also, what happens if the daemon goes away and there are existing clients? Do
these clients detect that the daemon has died and create a new one? What
prevents multiple daemons from coming up in such a situation, is it just the
directory lock? The new scheme will be a little different since there will be a
window whereby the lock file exists but the port/addr/password hasn't been
written to it yet, so the clients will have to spin their wheels until that data
does appear in the file. Any pointers on how to handle this?

	timeless
	Comment 33 • 21 years ago

A few notes, not in any particular order.

* I'm told the BeOS impl is nearly complete.
* a QNX impl should probably be implemented using something specific to QNX
(perhaps qnet, i'd have to refresh my memory)

The windows impl we have bothers me :)
There are cases where a profile could be shared with the wrong user (which the
unix version is supposed to not do for security reasons), and there are a bunch
of cases where profile sharing will fail for me (these are real for me, and do
occur in large installations/institutions).

I thought i had mentioned terminal services here, but i can't find any record
of it. For this i'm sorry. The topic was mentioned elsewhere under fast user-
switching. (comment 25)

Windows NT like other systems (unix/x11) allows you to do the following things:
1. Have multiple displays and desktops which can contact eachother.
2. Have multiple gui sessions which can't contact eachother.
3. Run gui processes as other users.
4. Host a profile on a unc \\server\username\profiledata
--
Netscape4 used EnumWindows to find itself which means that if you had multiple
desktops it wouldn't find itself which would allow you to run multiple
instances of it (each needed a distinct profile). -1

FindWindow which is used by the win IPC impl has the same limitation.
--
Terminal Services and Fast User Switching.

When I use windows 2000 (raistlin), I run a terminal services client on my
laptop (tardis) and then run mozilla in it. I'm also likely to run mozilla on
raistlin. If some version of mozilla supported profile sharing, then i'd expect
my profile to be shared by these two sessions. However there's no common window
so it can't possibly happen. -2

With Windows XP, microsoft is more aggressively pushing terminal services,
mostly under the fast user switching branding.
--
Suppose that a user is running mozilla (timely) and I need to install software
using mozilla. I might runas /user:timeless /profile mozilla (this is possible
from the gui too). My expectation is that Mozilla will load timeless's profile.

However my reading of the ipcdWin code indicates that's not what will happen. -3
--
This last one is a stretch, but not a very big stretch. Suppose that tardis was
configured to login to raistlin and load timeless's profile. An ideal profile
sharing system would let me share the profile between mozilla running as
timeless on raistlin and mozilla running as timeless on tardis. -4
--

Is there a way to implement ipc for windows which doesn't have these
limitations? I think mailslots would actually handle all 4. FWIW, 3 and 4 also
occur on 9x.

	Colin Blake
	Comment 34 • 21 years ago

timeless, is BeOS using named pipes, do you know?

	Darin Fisher Reporter
	Comment 35 • 21 years ago

>Changing the sockets to be INET instead of LOCAL doesn't seem too difficult, 
>the part that I'm not so sure about is sending/receiving the randon number 
>which prevents someone from port scanning. If you could give me some pointers 
>as to where in the code would be best to handle that, it would help a lot.
>
>Also, what happens if the daemon goes away and there are existing clients? Do
>these clients detect that the daemon has died and create a new one? What
>prevents multiple daemons from coming up in such a situation, is it just the
>directory lock? The new scheme will be a little different since there will be a
>window whereby the lock file exists but the port/addr/password hasn't been
>written to it yet, so the clients will have to spin their wheels until that 
>data does appear in the file. Any pointers on how to handle this?

well, for starters, the directory and lock file are created by the daemon.  in
the case of LOCAL sockets, the daemon also creates the socket (it calls bind).

startup is currently not optimal.  the client will attempt to connect to the
socket, and if that fails it will spawn a daemon process.  the daemon process
uses the lock file to prevent multiple instances of the daemon in case two are
starting up at the same time.  the one that loses the race to acquire the lock
will simply exit.  while the daemon is starting up the client will sleep for 50
milliseconds.  when that interval expires, it will wake up and try to connect
again.  it only attempts to spawn the daemon once, and will keep trying to
establish a connection to the daemon periodically.  at some point it will give
up.  there is no attempt made to restart a crashed daemon or anything like
that.  for users, loss of the daemon is roughly equivalent to loss of the app.

once a daemon is started, it has an initial client reference count of zero.
upon each accepted connection, the daemon increments its client reference
count.  if that count reaches zero, then the daemon will exit.  care is taken
using the lock file to ensure that once the daemon stops accepting connections
that another daemon instance would be able to take its place.

we probably won't have to worry too much about modifying the client polling
since that happens at a higher layer.  most of the code we'll care about
modifying is in ipcSocketProviderUnix.cpp (not sure yet if we want to create a
new file for this or just #ifdef the existing one).  finally, there is code in
daemon/src/ipcdUnix.cpp that we will need to modify.

one big thing to keep in mind.  to avoid a race condition in the multiple
daemon problem, we currently never delete the lock file.  (we depend on the
typical /tmp cleanup cron jobs that exist on most systems; most linux distros
anyways.)  this is not exactly optimal, but it greatly simplifies the locking,
and it seems to be the norm for many applications on my linux box anyways.
anyhow, because of this, you probably don't want to store the port number and
secret key in the lock file.  instead, you probably want to store it in a
separate file next to the lock file.  before shutting down, the daemon should
probably clear this file.  i think it should be able to do that before
releasing the lock.  if we crash, however, we might end up leaving around stale
info.  that would be bad since if another process were running on that port,
we'd potentially send out the secret to the wrong process.  we could help
minimize that by requiring the daemon to send a secret as well or something
like that.  i still need to think it over some more.

darin

	Darin Fisher Reporter
	Comment 36 • 21 years ago

timeless:

>* I'm told the BeOS impl is nearly complete.

great!


>* a QNX impl should probably be implemented using something specific to QNX
>(perhaps qnet, i'd have to refresh my memory)

why?  surely it supports at least TCP/IP, in which case it can share the impl
we are developing for OpenVMS.


>The windows impl we have bothers me :)
>There are cases where a profile could be shared with the wrong user (which the
>unix version is supposed to not do for security reasons), and there are a bunch
>of cases where profile sharing will fail for me (these are real for me, and do
>occur in large installations/institutions).
>
>I thought i had mentioned terminal services here, but i can't find any record
>of it. For this i'm sorry. The topic was mentioned elsewhere under fast user-
>switching. (comment 25)
>
>Windows NT like other systems (unix/x11) allows you to do the following things:
>1. Have multiple displays and desktops which can contact eachother.
>2. Have multiple gui sessions which can't contact eachother.
>3. Run gui processes as other users.
>4. Host a profile on a unc \\server\username\profiledata
>--
>Netscape4 used EnumWindows to find itself which means that if you had multiple
>desktops it wouldn't find itself which would allow you to run multiple
>instances of it (each needed a distinct profile). -1
>
>FindWindow which is used by the win IPC impl has the same limitation.
>--
>Terminal Services and Fast User Switching.
>
>When I use windows 2000 (raistlin), I run a terminal services client on my
>laptop (tardis) and then run mozilla in it. I'm also likely to run mozilla on
>raistlin. If some version of mozilla supported profile sharing, then i'd expect
>my profile to be shared by these two sessions. However there's no common window
>so it can't possibly happen. -2

the "profile sharing" feature, despite its name, is not meant to allow two
instances of the same application access to the same profile instance.  it is
meant to support a suite of applications (different executables) sharing the
same profile data.  e.g, standalone mail and browser.  the problem with
multiple instances of the same product is that the profile will actually be
partitioned into shared content and app specific content.  the app specific
content will contain the non-shared data.  today, that includes everything but
the set of shared prefs.  the profile lock that exists today will be moved into
the per-app directory.  so, what you are trying to do here is still
(unfortunately) going to require a separate profile just as it does today.

way way way in the future when we maybe have everything shared, we might be
in a position to support a fully shared profile.  but that goal is so distant
at this point.


>--
>Suppose that a user is running mozilla (timely) and I need to install software
>using mozilla. I might runas /user:timeless /profile mozilla (this is possible
>from the gui too). My expectation is that Mozilla will load timeless's profile.
>
>However my reading of the ipcdWin code indicates that's not what will happen. -3

hmm... i'm not sure i completely follow your example here.  can you please
spell out the steps more completely.  i don't understand the arguments you
mentioned... or at least i don't get what application would have those
areguments passed to it.  please clarify so i don't misunderstand your point.


>--
>This last one is a stretch, but not a very big stretch. Suppose that tardis was
>configured to login to raistlin and load timeless's profile. An ideal profile
>sharing system would let me share the profile between mozilla running as
>timeless on raistlin and mozilla running as timeless on tardis. -4
>--

yeah, might be nice, but that's not a goal.  we are really mostly concerned
about supporting an app suite run as a whole on one desktop under one user.
that is the primary goal.  i don't have the means to test anything else.  if
you want to implement an alternate IPC solution for windows, then by all means
feel free.  patches are always welcome.

darin

	Paul
	Comment 37 • 21 years ago

The current code for IPC builds under BeOS, but, I am not completely sure on how
to test it, though, I admit, I haven't looked into testing it too much yet, but
I will be soon.  It uses the Unix code for its implementation.

I do have, however, the beginnings of a BeOS implementation based on BMessages,
which, is a LOT simpler than the Unix impl.  I stopped working on it, once
timeless got the Unix code building under BeOS.  I may try to complete it at
somepoint anyway.

	Colin Blake
	Comment 38 • 21 years ago

I see there are some test modules. Do they actually build and work?

	timeless
	Comment 39 • 21 years ago

login as timely (mortal)
run mozilla as timely
suppose java isn't installed, but needs to be, and needs to be done by an admin

runas is like sudo. it lets you run a process as another user. (requires auth)
runas mozilla as timeless (power user) with profile
the expectation is that the mozilla launched at this point would access
the profile of the user which ran it (timeless), not the profile that happens
to be running (timely's).

That should be enough to describe the problem, but unfortunately because of
the fact that the current impl is only for sharing a profile among unlike
applications, i'll have to make one modification:

for some reason timeless runs mozilla-browser first to install something.
timeless doesn't close it.
timely runs mozillamail.
profile sharing kicks in and gives timely access to timeless's mail prefs,
possibly its accounts.

(this depends on how passwords are handled, both by profile sharing and by
timeless - did timeless configure mozilla to know the mail passwords?)

the use of timely/timeless is to make the situation hypothetical.
you could read them as darin/administrator, or darin/root.

as for lack of means, i'll give you a url for switcher so you can at least test
multiple desktops.

about QNX,... well, it depends on the goal. if the goal is as you're describing
it and not as i envision the feature or as it could be in the future, then
it's mostly pointless. QNX6.2 can simply use the domain version, and
anyone else can simply have a profile MDefault for mail and a profile BDefault
for browser and be done with it.

Do you have a list of preferences for which the user gains some benefit when
they're shared between distinct applications?

To me this seems like a very large amount of effort for a very limited and
entirely unknown win. Where's the problem description and where are the design
docs?

--
Colin: I'm told that BeOS is using BMessages.
--

Back to my problem scenarios in windows.

Suppose I have one profile and one account on a terminal server.
suppose i login twice, the first time i run mozillaBrowser
the second time i try to run mozillaMail.

Since i originally configured my profile as owning my mail, i'm now locked out
of my mail for the foreseeable future(probably until 1.8) because we decided to
use profile sharing with this implementation instead of simply forking
unrelated profiles for unrelated applications.

It seems to me that I'd be much happier having a profile for mail and a profile
for browser. And no, your average me doesn't get a choice, profile sharing if
implemented would only show a profile manager dialog after the first profile
data was locked, not when the user first configured mail and browser.

Forking has the additional benefit of not burdenning a Browser with pref data
for a mail client and vice versa. (And it's a great opportunity to discard
unused legacy prefs.)

As for the current code that builds on BeOS, that's supposed to just build
enough so that it can return a failure message if something tried to use it.
I don't think it would actually work.

	Colin Blake
	Comment 40 • 21 years ago

> Do you have a list of preferences for which the user gains some benefit when
> they're shared between distinct applications?
>
> To me this seems like a very large amount of effort for a very limited and
> entirely unknown win. Where's the problem description and where are the design
> docs?

Now we're getting somewhere. 

Startup time is already an issue on most/all platforms. Profile sharing will
adversely affect startup time since we have to fork a daemon, wait for it to
fire up, and then communicate with it. I don't think people are going to want a
slowdown, not unless there's some other huge benefit for them. And at this
point, I don't see it.

Add to that the fact that if the daemon dies then all the apps are toast, and I
think you have a "feature" that no one is going to want.

So tell me again, why do we need this? What are the benefits?

	Darin Fisher Reporter
	Comment 41 • 21 years ago

You want to use TestIPC to verify that things work.  In a debug build enable the
IPC_LOG_ENABLE environment variable and check the output (against a build from
another unixy platform).

the test code should all work.


>Add to that the fact that if the daemon dies then all the apps are toast, and I
>think you have a "feature" that no one is going to want.

if the app dies, the app is toast.  what's the difference if the daemon is the
one to die?  anyways, the app will continue in some manner... maybe the users
shared settings will either not be persisted or not be accessible in some
manner.  it shouldn't be looked at any differently than if mozilla crashed.  we
don't try to recover from a mozilla crash, right?


>So tell me again, why do we need this? What are the benefits?

please see the documents on profile sharing... IPC is a feature that supports
profile sharing.  in addition it can be used to support remote xpcom, explicit
discovery of other apps on the system under generic names like "browser", "mail"
or "addrbook".  it helps solve a lot of problems that i anticipate will come up
once the moz apps are split up.  the profile sharing docs are here:

http://www.mozilla.org/projects/embedding/profileSharing/

there are many many things that we need to share above and beyond prefs.  true
that is all that is currently working, but we needed to start somewhere.

	Darin Fisher Reporter
	Comment 42 • 21 years ago

paul:

are you sure you want to maintain a fork of the IPC code specifically for BeOS?
 is it really worth it if UNIX domain sockets work?


timeless: 

while true you could use this IPC mechanism to have two user accounts (with
access to the same GUI) share information, that does not automatically mean that
the profile sharing system will have user A access user B's profile data.  in
fact, the IPC daemon is capable of supporting multiple profiles.  each
application when it starts up is going to tell the daemon (actually the
transaction manager in the daemon) that it is interested in changes for specific
"queues" which really represent specific files on the system.  so, in your
example the runas command would indeed use the proper profile.

	Paul
	Comment 43 • 21 years ago

darin:  No, not really.  I had started work on a BeOS impl. before I knew
timeless was working on this.  If the UNIX socket code works under BeOS, I don't
see a point in using the work I started.

	timeless
	Comment 44 • 21 years ago

err, let's try to be clear about this...
i don't think classic BeOS has domain sockets (google showed random configure
scripts list QNX and BeOS together in that category). My changes enable ipc to
compile (presumably) without any functionality. It's a stopgap so people don't
have to add a flag --disable-whatever while they wait for Paul to write the
BMessage impl.

Darin: I've read those pages. I still don't see any benefit.
We have lots of security concerns about mail and cookies.
It seems to me that *not* sharing cookies between mail and browser would be a
*good* thing.  As for cache, I'm not sure how often people get large amounts of
content via email which requires them to use a cache. If it happens a lot then
I think I'd want to worry about the state of the world.

So here's a list:
prefs
 - most of the preferences are either dead or unrelated to a given application
   as such I'd want to fork prefs and only migrate relevant ones.
bookmarks
 - I don't think people need them outside of browser.
   I can see uses for them, but we never implemented them.
history
 - Mozilla/5 hasn't had the ability to handle 'alt-left' in recent memory.
   I used this feature a lot when I used Netscape 4's Messenger.
   Since the feature didn't make it into the new world, I have to conclude that
   it wasn't really important to anyone, which means that at least one kind of
   history wasn't useful to mail. (That's session)
 - The other kind of history (global) is like cookies, we support it, but it
   probably doesn't add much value although with css it allows certain privacy
   attacks, and if people really want the benefit of global history they'd
   probably benefit from loading the url in the browser of their choice.
cookies
 - See various bugs on cookies from mail. I don't think I know of any good uses
   for cookies in mail. A distinct cookie jar for mail seems better to me.
plugins
 - I don't need plugins in my email. I suppose some people might.*
   I'd rather see plugins be a browser only thing. like history if they really
   want the benefit of plugins then we should enable them to load the email in
   a browser sandbox.
  * I'd love to hear a justification for supporting plugins in mail, but that's
    offtopic so it can be made privately.
password manager/form fill
 - Yes both mail and browser have forms, but do they actually need to share
   any of their form data? in fact IMO the user interface for the two things
   should probably not be the same. And the data being stored is generally
   distinct.
certificates
 - This is the only item where i see some use for a daemon, and in fact PSM1
   was such an animal.  The old code probably still exists, although people
   didn't like it much.
 - I'm not sure how useful this item is either.  If you receive a certificate
   for your web server in email, then you can either save it and import it into
   your browser, or open it with your browser. In fact, such a certificate
   would probably be for a web server, not a browser...
 - If you receive a certificate for your email account from a web server then
   you can save it and import it into your email client, or open it with your
   email client. -- You have to do this anyway if your client isn't some GRE
   item.

Again, what problem are you really trying to solve and do you really see it as
a problem worth solving in this manner?

A daemon which actually let me run multiple Browsers against a shared cache/
cookie/history profile might be useful, but that's clearly not in the current
cards.

> IPC mechanism to have two user accounts (with
> access to the same GUI) share information,
eek. i'm pointing out that by default it looks like this bleeding *would*
happen.
> that does not automatically mean that
> the profile sharing system will have user A access user B's profile data.
It won't. the profile sharing system will have one of A or Bs data, and will
improperly give that data to an application which should have gotten data
from a different profile which should have been managed by a *different*
daemon.
> so, in your example the runas command would indeed use the proper profile.

I tried to make this clear.
w2k user:timely. has one mozilla profile 'default'
w2k user:timeless. has one mozilla profile 'tluafed'

The first sharing application runs as timely and starts sharing 'default'.
When an application run as timeless on the same desktop starts, it finds
timely's daemon and asks it for profile data ('default'). There's no
reason for the sharing application running as timeless to know that the
daemon it found for 'default' is for the wrong user (timely) /
profile (something that is not 'tluafed').

The code doesn't seem to do any check.

	Darin Fisher Reporter
	Comment 45 • 21 years ago

timeless:

this is not the place for a discussion about the worth of the current profile
sharing plan.  if you wish to discuss that take it elsewhere... like try a
newsgroup.  i'm not interested in arguing the merits of profile sharing with you
in this bug.

>A daemon which actually let me run multiple Browsers against a shared cache/
>cookie/history profile might be useful, but that's clearly not in the current
>cards.

hello!  i never said this wasn't a goal.  i only said that the inital goal is to
support an application suite.  do you not understand the concept of small steps?


>I tried to make this clear.
>w2k user:timely. has one mozilla profile 'default'
>w2k user:timeless. has one mozilla profile 'tluafed'
>
>The first sharing application runs as timely and starts sharing 'default'.
>When an application run as timeless on the same desktop starts, it finds
>timely's daemon and asks it for profile data ('default'). There's no

given what i said, this is incorrect.  the second instance of mozilla run by
timeless would ask the daemon (run by timely) to share the 'tluafed' profile.
think of the profile name as a namespace.  each application tells the daemon
what profile it will be using.  get it?

darin

	timeless
	Comment 46 • 21 years ago

Ok, so what happens when a daemon running as the wrong user tries to make
changes to a profile?

my point is that the code that looks for a daemon *must* not look for a daemon
owner by anyone else.

it could screw up permissions (including resulting in encrypted files which the
user can no longer access) or simple dataloss if it has the ability to delete 
a file but not replace it. it's actually possible under windows xp for drive
letters to be restricted to a given user's credentials). it could just fail.
it could create a profile with the wrong owner.

	Darin Fisher Reporter
	Comment 47 • 21 years ago

>Ok, so what happens when a daemon running as the wrong user tries to make
>changes to a profile?
>
>my point is that the code that looks for a daemon *must* not look for a daemon
>owner by anyone else.
>
>it could screw up permissions (including resulting in encrypted files which the
>user can no longer access) or simple dataloss if it has the ability to delete 
>a file but not replace it. it's actually possible under windows xp for drive
>letters to be restricted to a given user's credentials). it could just fail.
>it could create a profile with the wrong owner.

only a broken application could fall into this category.  it won't even be
possible for a user to make one of the mozilla apps behave this badly unless of
course the second user truly has access (file access) to the first user's
profile.  but, even then... the user would have to explicitly add the other
user's profile to the mozilla profile registry.  so, i really think this is a
non-issue.  clearly both user accounts are under the control of the same human
being or else you'd be talking about a breach of security in windows.

	Darin Fisher Reporter
	Comment 48 • 21 years ago

timeless: let me spell it out with an example...

consider these two user accounts (Win32 profiles):

  \\Host\UserA
  \\Host\UserB

mozilla applications are going to look in 

  \\Host\%USER%\Application Data\Mozilla\registry.dat

to find the list of profiles belonging to %USER%.  mozilla apps will only select
a profile from that set.  therefore any profiles belonging to UserB will not be
accessible to UserA unless one hacks the registry and gives UserA sufficient
file permissions to access profiles under \\Host\UserB\.

make sense?

	Disreali
	Comment 49 • 21 years ago

Paul, BeOS still crashes because of IPC if --disable-profilesharing is left out of the mozconfig. Build attempt 5-16-2003 using current cvs checkout.

	Paul
	Comment 50 • 21 years ago

Well, I have most of IPC implemented for BeOS.  Currently, there is a crash in ipcStringList, when the test tries to run a query by name.  I am doing a full update of my tree right now, and will be doing a full re-build.  Once done, I will finish off the port, and submit my patch.  If the current code in CVS does not work, well, just wait until I submit my patch, as I see no point in me fixing anything w/o a proper impl.darin:While working on the port, I noticed that in the ipcMessage class, the WriteTo and ReadFrom methods can only be called once per instance.  I guess that makes sense for ReadFrom, but, for WriteTo, shouldn't the mMsgOffset be reset, once the write has been completed, so, the method can be called a second time?  Or, I could be completely missing something. ;-)

	Disreali
	Comment 51 • 21 years ago

It seems I getting the make errors on older src. I pulled todays src, 
20030518, and MozFB compiled without an error and the browser works well. 
Sorry to have caused any problems.

	Paul
	Comment 52 • 21 years ago

Ok, I finished off an initial port to BeOS.  The TestIPC program runs, and seems
to be successful, though, I am not completely sure.  Plus, some of the code in
the test is commented out, which, keeps the TestIPC programming running in a
loop on the event queue.

I do have a question though, before I submit a patch:  Will there be only one
client per application instance?  In other words, would Mozilla, Firebird and
Thunderbird, if setup to use IPC, only create one ipc client each for a total of
three client instances?  Or, could, say, Mozilla create multiple instances of
the ipcClient?

	Darin Fisher Reporter
	Comment 53 • 21 years ago

Paul: ipcClient is just a class representing each client connection, and each
application need only establish one connection to the IPC daemon.  so, in your
example there would be a total of 3 ipcClient classes allocated.

	Paul
	Comment 54 • 21 years ago

That was my guess, but I wanted to make sure, as my code would require some
additional changes if it were any other way.  I should be submitting a patch soon.

	Darin Fisher Reporter
	Comment 55 • 21 years ago

retargeting to 1.5 alpha... remaining work is mostly cleanup and moving the code
onto the trunk.  1.4 final can be happy pulling the IPC branch i think.

	Paul
	Comment 56 • 21 years ago

Ok, here is a BeOS impl. for the IPC mechanism.

Client: Creates a BHandler and attaches it to the current be_app to process
messages coming from the daemon
(had to modify TestIPC.cpp to have it spawn a BApplication, like
nsAppRunner.cpp in xpfe/bootstrap)

Daemon: A simple BApplication for receiving/sending messages to/from clients
- spawns a BMessageRunner to periodically send Purge messages to itself for
removing stale clients

Currently, when the last client is removed, the ipcLockModule crashes the
daemon in ipcLockModule_ClientDown while enumerating the hash.	Not completely
sure why, yet, but will investigate
Also, the daemon creates an entry on the DeskBar (do to the fact that it is a
BApplication), which, I would like to see if I can prevent from happenning.
Other than that, it seems to work, at least, the TestIPC doesn't complain about
anything.

	Paul
	Comment 57 • 21 years ago

This fixes the DeskBar issue I mentioned in the last patch by adding a resource
file for the daemon, which indicates that the app is background only.

There still is an issue with the Test crashing, though, sometimes it works,
sometimes its the daemon, and sometimes the TestIPC app itself.  This indicates
to me that there is a threading issue involved.  One place I can think of, is
that the Client's MessageReceived code is running in the BApplication's thread,
so, for the client, we will need a way to have the BApplication communicate
with the proper thread within the test.  This will also be needed once
Mozilla/Firebird/etc. all become actuall clients, and this code is used.
I am still unsure about the daemon crashing, though, as there is only one
thread for the daemon ever spawned (everything runs in the daemon's
BApplication thread)

	Darin Fisher Reporter
	Comment 58 • 21 years ago

bumping target milestone... not sure what the real target for this should be.

	Colin Blake
	Comment 59 • 21 years ago

Can someone confirm that having IPC is NOT required for 1.5 (no significant
functionality will be lost). This is what I was told a couple of months ago, I
just want to make sure that it still holds.

	Darin Fisher Reporter
	Comment 60 • 21 years ago

colin: like i said in my previous comment, i don't know what the real target of
this is or should be.  it doesn't seem like profile sharing will be in use by
firebird and thunderbird during the mozilla 1.5 milestone, but i could be wrong.

	Darin Fisher Reporter
	Comment 61 • 21 years ago

this is off the radar now...  it doesn't look like firebird and thunderbird want
to share profile data.  -> future

	Brendan Eich [:brendan]
	Comment 62 • 21 years ago

This may make a comeback for cert-sharing among the 'birds, unless someone makes
Thunderbird an add-on to Firebird that runs in-process.  We'll want something
for certain customers who use both 'birds and care about PKI.

/be

	timeless
	Comment 63 • 21 years ago

why not go back to psm1 ;-?

	Darin Fisher Reporter
	Comment 64 • 21 years ago

timeless: because PSM1 was slow.  all data was passed over the IPC connection. 
in the case of sharing certs, all we really need to do is share the certs.  NSS
is already setup to optionally access the cert db through a special interface. 
all we need to do is implement that interface in terms of the ipcIService and
implement a module for the IPC daemon that access the .db file(s).

	Wolfgang Rosenauer [:wolfiR]
	Comment 65 • 21 years ago

sorry, I didn't follow the profilesharing thing in the past.
According to the bugs and the discussion profilesharing is not ready yet?
So Moz 1.6 actually don't use it?
If so, why are the components in mozilla.org's packages?
Is it possible to build mozilla with --disable-profilesharing without loosing
features at this time?

	Darin Fisher Reporter
	Comment 66 • 21 years ago

> sorry, I didn't follow the profilesharing thing in the past.
> According to the bugs and the discussion profilesharing is not ready yet?

right, it is not ready yet.


> So Moz 1.6 actually don't use it?

right


> If so, why are the components in mozilla.org's packages?

good question.  we don't need to be shipping the components; however, they are
relatively small :-/


> Is it possible to build mozilla with --disable-profilesharing without loosing
> features at this time?

yes


i think firefox is built with that option.

	Darin Fisher Reporter
	Comment 67 • 20 years ago

FYI ports maintainers: there is new discussion about profile sharing going on
again.  It might very well translate to enabling some of the profile sharing
implementation in an upcoming milestone.

	Christian Persch (GNOME) (away; not receiving bug mail)
	Comment 68 • 19 years ago

(In reply to comment #64)
> NSS is already setup to optionally access the cert db through a special 
> interface. all we need to do is implement that interface in terms of the 
> ipcIService and implement a module for the IPC daemon that access the .db 
> file(s).

I'm interested in this; where can I find information about this NSS interface?

	Darin Fisher Reporter
	Comment 69 • 19 years ago

chpe: you should talk to wtchang.

	Enrico Weigelt
	Comment 70 • 17 years ago

Oh hell, why do you alway make such easy things that complicated ?!

Why not simply utilize an the widely supported OS feature called "filesystem" ?
Nearly all filesystems support locking - for those which dont, dot-locking should do the trick.

The key is to use an well-suited storage format, which models every autonomous record (ie. an bookmark) as its own inode. Concurrent access (between several applications as well as different users) would be as trivial as things like bookmarks from external sources, ie. collaborative bookmarks or rss-feeds. By using an an (separate) userland filesystem layer, those things could simply be mounted-in. 

I really suggest you to do some little studies on how Plan9 handles those things.
It's the perfection of good-old Unix' philosophy "evrything's an file". 

IMHO, 9p2000 would be an good mechanism for talking to the filesystems:
An simple userland client library handles the connections 9p2000 servers and supplies an clean and simple API for evrything else. On application startup, we run an init-routine which mounts the required datasources and starts servers when necessary. After that point, we just use an filesystem - nothing more. 

Bookmarks, Cookies, Certs, etc are all stored in that filesystem. 

If someone wants some non-standard setting (ie. get profile data from some server like ldap, collaborative bookmarking, rss-bookmarks, ...), all he has to do is choose the right 9p2000 server (or write one if necessary) and mount it in.

All these problems are immediately off the scope of mozilla at this point.