Re: Registering Clients using DO
Re: Registering Clients using DO
- Subject: Re: Registering Clients using DO
- From: Kiran Kumar S <email@hidden>
- Date: Tue, 5 May 2009 11:10:45 +0530
hi ken,
So, the questions are: is -getServer called on the main thread? Is
the client object, the one which you pass to the server with -
registerClient:. retained so that it is still alive when the ping
comes?
the object i send is shared object, which exist until the application
quits.
Regards
SKiran
On 30-Apr-09, at 2:08 PM, Ken Thomases wrote:
On Apr 30, 2009, at 3:06 AM, Kiran Kumar S wrote:
On 30-Apr-09, at 12:03 PM, Ken Thomases wrote:
On Apr 30, 2009, at 12:47 AM, Kiran Kumar S wrote:
I am developing a client/server application using DO. In server
an object is vended to be accessible by clients.In the client
side i am accessing vended object and get required info from
server.Every thing works fine. Until now my client queries server
and server replies to that. But on serverside if any updates
goes, i had to inform client.so i thought of registering the
client and ping the client for updates.So in Client side i get
vended object and registered it to server.When my server pings
the client its giving error *** NSDistantObject initWithCoder:
0x1 not given away for conn 0xf8937f0
Can you break on this error? On what line of code is it
happening? What's the backtrace?
this exception occurs when server pings,
2009-04-30 13:22:13.835 Project X[7044:10b] *** NSDistantObject
initWithCoder: 0x1 not given away for conn 0x10c17ce0
It looks like the above is separate from the below exception,
although probably related. That message is far from clear. An
Apple engineer may be able to help.
It seems to be saying that it has received an object identifier
(0x1) which doesn't correspond to any object that was sent out on
the connection in question.
2009-04-30 13:22:13.836 Project X[7044:10b] NSExceptionHandler has
recorded the following exception:
NSInternalInconsistencyException -- *** -[NSConcretePortCoder
decodeInvocation]: no local target
Stack trace: 0xb5919a 0x94372e3b 0x95d8aeeb 0x95d8af2a
0x90e847bc 0x90e8425d 0x90e8074c 0x90e8386e 0x90e8358d
0x90e830be 0x90fc4395 0x90fc37ae 0x95d1a87c 0x95d1bf65
0x95d115f5 0x95d11cd8 0x910e9480 0x910e9299 0x910e910d
0x96bff3ed 0x96bfeca0 0x96bf7cdb 0x38de9a 0x96bc4f14 0x37225
0x27a6 0x1
An Project X exception of type NSInternalInconsistencyException
occured.
*** -[NSConcretePortCoder decodeInvocation]: no local target
Stack trace:
1 +[NSException raise:format:arguments:] (in CoreFoundation) +
155
2 +[NSException raise:format:] (in CoreFoundation) + 58
3 -[NSConcretePortCoder decodeInvocation] (in Foundation) + 1068
4 -[NSConcretePortCoder decodeRetainedObject] (in Foundation) +
909
5 _NSWalkData2 (in Foundation) + 1724
6 -[NSConnection handleRequest:sequence:] (in Foundation) + 78
7 -[NSConnection handlePortCoder:] (in Foundation) + 1149
8 -[NSConcretePortCoder dispatch] (in Foundation) + 142
9 -[NSSocketPort _handleMessage:from:socket:] (in Foundation) +
821
10 __NSFireSocketData (in Foundation) + 734
11 __CFSocketDoCallback (in CoreFoundation) + 476
12 __CFSocketPerformV0 (in CoreFoundation) + 133
13 CFRunLoopRunSpecific (in CoreFoundation) + 3141
14 CFRunLoopRunInMode (in CoreFoundation) + 88
15 RunCurrentEventLoopInMode (in HIToolbox) + 283
16 ReceiveNextEventCommon (in HIToolbox) + 374
17 BlockUntilNextEventMatchingListInMode (in HIToolbox) + 106
18 _DPSNextEvent (in AppKit) + 657
19 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 128
20 -[NSApplication run] (in AppKit) + 795
21 -[MainApp run] (in Project X) (MainApp.m:506)
22 NSApplicationMain (in AppKit) + 574
23 main (in Project X) (main.m:28)
2009-04-30 13:22:16.422 Project X[7044:10b] *** -
[NSConcretePortCoder decodeInvocation]: no local target
@implementation ServerObject : NSObject
-(void)registerClient:(id<NetClientProto>)client {
You didn't show the NetClientProto protocol, although I'm guessing
it's pretty simple.
You didn't comment here. I guess I was too subtle. I was asking to
see the protocol declaration.
[serverObject performSelector:@selector(registerClient:)
withObject:self];
Why are you using -performSelector:... here? What's the
declaration of 'serverObject'?
Best practice is to have a protocol for each side of the
connection, defined in a header that is shared between the code
bases. Then you don't have to relying on things like -
performSelector:... You could just invoke -registerClient:
directly.
Such a protocol is also where you'd specify bycopy, oneway, and
similar specifiers.
Furthermore, you should use -[NSDistantObject
setProtocolForProxy:] for efficiency, and probably
NSProtocolChecker (on the server side) for security.
Thanks , and i will probably implement this
It -- the use of a protocol and avoiding the need for -
performSelector:.. -- may actually be important for the correctness
of the registration of the client. So, you should try it to see if
it fixes the problem.
Is your client then running its run loop, waiting to be pinged?
Is it the same thread and run loop where -getServer was called?
No, client is not running in runloop, waiting to be pinged, can u
please suggest me how to do this
According to the backtrace you showed above, the client process is
in fact waiting in a run loop. It appears to be an application in
its main event loop, -[NSApplication run].
So, the questions are: is -getServer called on the main thread? Is
the client object, the one which you pass to the server with -
registerClient:. retained so that it is still alive when the ping
comes?
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden