Re: Distributed Objects pitfalls and strategies
Re: Distributed Objects pitfalls and strategies
- Subject: Re: Distributed Objects pitfalls and strategies
- From: Aurélien Hugelé <email@hidden>
- Date: Wed, 31 Mar 2004 13:54:57 +0200
On 31 Mar 2004, at 12:01, Wade Tregaskis wrote:
i tried to call simply "run", and that works of course, except that
when i close the connection, the runloop does not exit ! using
NSLog() i saw that there were many other "input sources" added to the
runLoop... (maybe as you said poor design/management but i did not
added anything myself like timer etc...). Even chris kane (the only
person at apple that explained and give a piece of code about DO)
often says on this list that you can't really control the input
sources added to the current runloop (it depends on the frameworks
you use etc...) so he advices to poll in a while loop !
Hm... this is true. I must admit my only recent DO projects have all
been controlled enough on the server side to avoid these sorts of
issues (i.e. I don't use any framework other than Foundation).
yes the best solution is to minimize the call to any Cocoa object that
add input sources to the runLoop, but i think it is quite difficult to
control ! bravo !
Polling once a second is, as always, an undesirable option.
basically, the "run" method is based on "runUntilDate: /
runBeforeDate: " variant and ACTUALLY poll the run loop ;)
i choosed to poll every one second, but the 1 second was a total
guess, i don't know if i should poll less often or more often...
The advantage with letting the run loop code handle it is that it can
be updated to whatever threading/process/etc model Apple feel like
using, making optimum use of it. E.g. it may not poll, but rather use
interrupts of some sort (taking wild guesses here, but you get the
idea). Plus, it generally makes your code shorter. :)
you are right, but i'm pretty sure apple does not optimize it at all,
re reading the Chris Kane messages on this list make me think that the
run call is just polling... but i'm maybe wrong !
for the moment, polling the run loop every second consumes virtually no
CPU at all (mesured on my test project with top).
In fact i think the main problem with the 1 second polling is when the
client messages the server (which has just polled the run loop) must
wait 1 second before the server repoll the runLoop and see it has been
messaged... 1 second is a HUGE delay when dealing with networks (in
particular LAN !) so this slow the connection for nothing... thus, i
recognize that it is not beautifully designed ;)
i'm really interested in knowing how do you control the input sources
of the runLoop... how do you achieve to be *sure* there is only YOUR
connection(s) as input source(s)...
You need not do this, connecting back to the client. Why not just
have your client pass in it's representative object to the server's
register method? Save that whole slew of extra steps, and avoid
issues on the client side with port reuse.
can you explain what you call "it's representative object" (of the
client) ? if you talk about the proxy (the vended object) then i
tested it and it did not work for that reason : you can (AFAIK,
quickly tested) have only *one* vended object per connection !
so if the client use the *same* connection (created by the server),
the rootProxy is already the server ! the rootProxy can't be the
client...
i must recognize that, thinking about it, there is maybe no need to
set the client as the rootProxy : if the client just pass "self" to
the server back, then the server may have a *sort of* proxy of the
client (?) please confirm this :)
Yes, in essence.
Client -> connects to -> Server
Client -> asks for root proxy from -> Server
Client <- receives root proxy from <- Server
Client -> calls registerClient:self on -> Server [proxy]
In this example, the server object returned as the root proxy has a
method something like the following:
- (oneway void)registerClient:(id)clientObject;
This method can store the given object for later use. The
clientObject works exactly the same as if you had set up a separate
NSConnection and set the clientObject as the root proxy of that, then
had the server connect and request it. The advantage of course is
that you need only connect one way, and it's a whole lot simpler, if
you use the method I propose.
great, at the time i coded this, i did not think about this, but
writing my previous message i suddendly thought about the client
passing "self" to register itself... thanks to have confirmed this !
your code is indeed much more simpler and cleaner !!
I can't actually remember whether my port allows you to use it
without the security stuff, but if so it might be helpful to other's
having these sort of problems. If not, someone can probably hack it
up so it does.
what do you mean by security stuff ? you manage authentication over
DO ? or crypt the transferred datas ??
The purpose of my SecureSocketPort (not NSSecureSocketPort as I think
I mistakenly wrote previously) class is to replace a normal
NSSocketPort in your DO work, as transparently as possible, while
providing connectivity via SecureTransport - i.e. standards-based
commercial-quality authentication & encryption. In an ideal world
this would be laughably easy to do as a simple NSSocketPort subclass
or similar extension, but as I found out that just wasn't in the
cards.
The SecureSocketPort class is complete, btw, in so far as it doesn't
have any show-stopping bugs that I'm aware of. It's a hideous tangled
mess of spaghetti code inside, though, as a result of my convoluted
discovery process regarding the inner workings of DO. But it does
work, and provides about the same latencies (both local and over a
LAN) as a normal NSSocketPort, even with the encryption and all the
extras on top. I presume peak bandwidth would be limited as a result
of the encryption overhead, although in theory any of the popular
symmetric ciphers used in TLS/SSL should be lightning fast on a modern
CPU. The reality seems to be otherwise - I don't think I managed more
than about 10 meg a second in my crude benchmarks, but that was with a
debug build.
this open *very* wide areas to DO imho :D
i can think of several levels of data sharing : in a company, only a
limited group of people can access the full data when the clients can
only access a small part of the shared infos etc...
this is fantastic and give me many ideas for our current project !
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.
_______________________________________________
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.