Re: Distributed Objects pitfalls and strategies
Re: Distributed Objects pitfalls and strategies
- Subject: Re: Distributed Objects pitfalls and strategies
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 31 Mar 2004 09:21:46 +1000
Problems:
* Client hangs and gets timeout exceptions trying to resolve
connections after the server process has been stopped and started
again. e.g., a user logs out and another logs in.
I'm not familiar with the behaviour for users switching, but I'm
pretty sure no processes ever get paused or otherwise put on old.
Why exactly is your server process starting and stopping when users
log in and out?
Well when a user logs out, all of their processes are quit. Then
there's the case of fast user switching, which requires extra care
since only one NSConnection can exist per port per computer (afaik).
Ah, of course - sorry, I couldn't see the forest for the trees.
This is thus the same problem as the server dying unexpectedly, except
in this case you can go a step further and have your server send
shutdown notifications to all it's clients, when your app receives the
appropriate NSWorkspace notifications. That way your clients can
[hopefully] just close the connection immediately, provided your app
lives just long enough to get those messages out.
Problems:
* If there are multiple servers running on the network, then
messages sent to a connection's proxy go to a random server, not
necessarily the one the NSSocketPort was created for.
*boggle* That's a big of a disaster, innit? I've never heard that
one before... I've had multiple servers [of the same type, using the
same port] running concurrently without any such trouble. Of course,
in that particular scenario I've never created the sockets myself...
perhaps you're not configuring something correctly, or somesuch? I'm
not big on raw sockets, so I can't really suggest anything.
Right, this is only a problem when you set the socket on the client
side to allow port reuse.
I don't see why you need to use a certain port on the client...
regarding my other reply sent a few minutes ago [to another message in
this thread], you're not implementing a peer-to-peer system by having
the client open a separate server NSConnection, are you? If so, see my
other email - it doesn't have to be so hard! :)
I'm not sure how TCP connections could cross over as you describe;
I'm pretty sure they can't. Which implies the connection is being
frequently remade, and to the wrong address... or something. Do you
have any more details on this problem?
The issue is entirely on the client side. When the client tries to
make the remote NSConnection using a new NSSocketPort (with
SO_REUSEPORT) with the same port # as a previously made NSSocketPort
(with SO_REUSEPORT), the NSConnection is "pointing" to the wrong
server. I guess this is because the NSSocketPort was set to be reused,
and it's reusing the address as well (even though the SO_REUSEADDR
option is NOT set).
Strange... on the face of it this sounds like a sockets bug, then, if
it's behaving against it's configuration.
That of course still won't help if you do have a valid reason to be
regularly tearing down your server, but I suspect this probably isn't
the case. Can you provide any more details as to what and how you're
trying to do things? Perhaps you can avoid the problems you're
experiencing by taking a slightly different approach.
Again, nothing unusual. It's just that the program is a user-level
thing and many of my customers use Mac OS X multiple users (not
necessarily Panther fast user switching, but that too). So when one
logs out while there's an active connection to a client, the server
quits normally but the OS doesn't have a way to know that the
connection is no longer valid, and so just waits 10 minutes before
terminating it. If another user logs in before this 10 minute period
and opens the program, trouble ensues.
Fair enough.
One workaround, which I mention mainly for completeness and not because
I would generally recommend it, is to run your core server as a daemon
that survives logout... this avoids the port re-use issue, prevents
clients being disconnected when the logged in user(s) change, etc etc.
It might suit your design, might not.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.