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: Tue, 30 Mar 2004 23:42:42 +0200
i use dynamic private port, so i dont 't have the problem you explained
(but i encountered them of course at the beginning...)
now i have another solution which i have tried :
i have made a little c++ tool that run on a static port (without DO)
and that helped to manage the reuse of port problem... or that redirect
the connection to the right server on a dynamic private port ! (this is
quite complex and i don t remember much about this hack)
finally something i did *not* tried but seems to be *very* interesting :
the "TIME_WAIT state" : i strongly advice the best socket faq ever :
www.developerweb.net/sock-faq/detail.php?id=13
this, i think, would solve the problem of a crashing/quitting server
that uses a static port. As you said the port CAN NOT BE REUSED
immediatly !
In fact, it because **the kernel** keeps the socket port (or the socket
maybe) STILL ACTIVE (but in fact not usable since the server behing the
socket died...) for 120 seconds (IIRC this is the tcp default time for
TIME_WAIT...). And since the port/socket is active, the port can not
be reused !
you can change this !! with the TIME_WAIT set to 0, and the port is
IMMEDIATLY reusable...
AFAIU the faq, this *is* the solution :D
do you have time to try this ? if you succeed in anything, please
report !
good luck, this thread is now archived as a really important thread in
my Mail.app folder ;)
On 30 Mar 2004, at 21:54, John Scalo wrote:
>
Aurilien, thanks much for the input. Are you using a static port #, or
>
a new dynamic private port # each time? If you're using a static port
>
# and you're not setting the port for reuse, then I believe you will
>
have the same problems as I'm having if the server quits while there
>
is an active connection.
>
>
On Mar 30, 2004, at 7:57 AM, Aurilien Hugeli wrote:
>
>
> basically my method to implement *both way* communication using DO is
>
> always the same :
>
>
>
> SERVER :
>
> 1/i start a server connection and set the root object in a thread.
>
> 2/ the server publish a rendezVous service to show its presence using
>
> the port number of the connection created just above
>
> 3/ i make the thread "run almost forever" by looping as this :
>
> while(shouldContinueLooping && [theThreadRunLoop
>
> runMode:NSConnectionReplyMode beforeDate:[[NSDate date]
>
> addTimeInterval:1.0]])
>
> like this the server thread stops only when the
>
> "shouldContinueLooping" pass to NO... i dont know why but the
>
> run...untildate: variant does not work, i MUST use the
>
> run...beforeDate: variant...
>
>
>
> so the thread is listening to client requests until you pass
>
> shouldContinueLooping to NO.
>
>
>
> CLIENT CONTROLLER (singleton) :
>
> 1/ the client controller register for the rendezVous service
>
> published by the server
>
> 2/ when resolving the rdv service, start a thread that create a
>
> communication to the server port and keep the rootProxy (the server)
>
> 3/ create a CLIENT INSTANCE, pass it the server port and ip address,
>
> the rootProxy
>
>
>
> CLIENT INSTANCE :
>
> 1/ establish a connection with the server using passed infos above
>
> 2/ ask the server to register us ! (passing the server the client IP
>
> Address and the client port)
>
>
>
> SERVER AGAIN :
>
> 1/ check the CLIENT INSTANCE is not already registered etc...
>
> 2/ start a connection to the CLIENT INSTANCE to get its rootProxy
>
> (you should use enableMultipleThreads method here, but not the
>
> runInNewThread ! (it consumes 100% of the CPU !???))
>
>
>
> END :
>
> you now have a *BOTH WAY* (ala peer to peer), fully threaded,
>
> comunication between server and clients. you can have several
>
> servers on you lan, they see each other via rendezVous and don't have
>
> the same ports...
>
>
>
> i know this seems quite complex but it is very stable here with about
>
> 10 servers/ 10 clients (never tested more...) i sometimes have
>
> Exception problem with timeout when a server crashes (the DO is only
>
> a small part of the App and is not the source of the crashes ;) ) or
>
> the App is force-quitted...
>
>
>
> What is nice with this peer to peer communication is that when a
>
> client quits, it can warn the server to unregister it (=> the server
>
> won't hang or timeout when trying to talk with dead clients) and the
>
> clients are warned too when the server die...
>
> using the little bad tricks i explained at the beginning of this
>
> mail, i succeeded to minimize the timeout exception and hanging
>
> problem to the *very* little...
_______________________________________________
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.