Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Objects pitfalls and strategies

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.

References: 
 >Distributed Objects pitfalls and strategies (From: John Scalo <email@hidden>)
 >Re: Distributed Objects pitfalls and strategies (From: Aurélien Hugelé <email@hidden>)
 >Re: Distributed Objects pitfalls and strategies (From: Aurélien Hugelé <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.