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 20:01:01 +1000
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).
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 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.
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.
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.