remoting channel release?!?

[EdgarBM]

Hi,
I'm working with .NET Remoting. I have a problem
unregistering the server channel when I try to reuse it
closing and reopening it in the same application. The
second time I try to get an instance of the same channel
it returns an exception with socket code 10048 (already in
use).

My server code is,
....for openning:

myLocalClass = new TheRemoteClass();
channel = new HttpChannel (8888);
ChannelServices.RegisterChannel(channel);

ObjRef ref1 = RemotingServices.Marshal
(myLocalClass, "ClassURI");
....for closing:

ChannelServices.UnregisterChannel(channel);
channel = null;

GC.Collect (); //desperate attempt
GC.WaitForPendingFinalizers (); //desperate attempt

RemotingServices.Disconnect(myLocalClass);

....so, after calling the closing code I would like to call
again the openning code to restart the connection, but the
SocketException appears at "channel = new HttpChannel
(8888);"
The solution must not be to maintain the channel opened;
no way.

Is there any unknown bug? (I've read about a similar
problem in the Beta version)
Am I doing anything wrong?

Thank you in advance,
Edgar

[Patrick Steele [MVP]]

In article <a3****************************@phx.gbl>,
an*******@discussions.microsoft.com says...

I'm working with .NET Remoting. I have a problem
unregistering the server channel when I try to reuse it
closing and reopening it in the same application. The
second time I try to get an instance of the same channel
it returns an exception with socket code 10048 (already in
use).

According to this newsgroup post:

http://tinyurl.com/2vmp4

"If you look at the way sockets work, when you close them, unless you
specify otherwise, they will take a few minutes (I thought it
was more like 4 or 5) for them to become available. This is normal and
customary behavior. This is done to allow the remote
connection to actually timeout and recognize that the socket went away.
You can override it on the Socket to close immediately and
be recycled."

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele

[EdgarBM]

First of all, thanks for your reply Patrick.

I saw a similar solution somewhere but I tried waiting and
more than 20 minutes after, nothing happened.
Anyway, I'm using it on a server application being full of
different communication channels, so is not a good
solution that a remote process waits for the channel to be
restarted an unknown time after a reconfiguration...

Should this be the only solution?, any other way?

Thank you again,
EdgarBM

-----Original Message-----
In article <a3****************************@phx.gbl>,
an*******@discussions.microsoft.com says...

I'm working with .NET Remoting. I have a problem
unregistering the server channel when I try to reuse it
closing and reopening it in the same application. The
second time I try to get an instance of the same channel it returns an exception with socket code 10048 (already in use).
According to this newsgroup post:

http://tinyurl.com/2vmp4

"If you look at the way sockets work, when you close

them, unless youspecify otherwise, they will take a few minutes (I thought itwas more like 4 or 5) for them to become available. This is normal andcustomary behavior. This is done to allow the remote
connection to actually timeout and recognize that the socket went away.You can override it on the Socket to close immediately and
be recycled."

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele
.

[Patrick Steele [MVP]]

In article <a4****************************@phx.gbl>,
an*******@discussions.microsoft.com says...

First of all, thanks for your reply Patrick.
No problem.
I saw a similar solution somewhere but I tried waiting and
more than 20 minutes after, nothing happened.
Anyway, I'm using it on a server application being full of
different communication channels, so is not a good
solution that a remote process waits for the channel to be
restarted an unknown time after a reconfiguration...

Should this be the only solution?, any other way?

SOAP and remoting are not my strong points. I looked through the docs
an HttpChannel does have a "StopListening" method. Perhaps you could
try calling that before unregistering the channel.

In fact, maybe you could use the StopListening/StartListening instead of
unregistering and then re-registering the channel?

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele

[EdgarBM]

Thanks for your patience, Patrick,
I tried Start & Stop Listening insteed of Register &
Unregister and the solution also works, but with the same
behaviour.

I just can change the port number (at server and client)
everytime I reconfigure the application. So the work will
began automatically...not a fantastic solution, but it
seems the only way.

Thank you again,
EdgarBM

PS: if you never find a solution for this problem, please
send me any suggestion at eberengena @ appeyron . com.
THANK YOU!!

-----Original Message-----
In article <a4****************************@phx.gbl>,
an*******@discussions.microsoft.com says...

First of all, thanks for your reply Patrick.
No problem.

I saw a similar solution somewhere but I tried waiting and more than 20 minutes after, nothing happened.
Anyway, I'm using it on a server application being full of different communication channels, so is not a good
solution that a remote process waits for the channel to be restarted an unknown time after a reconfiguration...

Should this be the only solution?, any other way?

SOAP and remoting are not my strong points. I looked

through the docsan HttpChannel does have a "StopListening" method. Perhaps you couldtry calling that before unregistering the channel.

In fact, maybe you could use the StopListening/StartListening instead ofunregistering and then re-registering the channel?

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele
.

[EdgarBM]

I just found one working protocol (not a coding solution)
which can make that the server can reuse the port
inmediatly after the reconfiguration: after unregistering
the server port, if the user tries to connect again to
this closed port, the port on the server will be set free
again!

....it's a "logical" behaviour if we think that the port
can't be reused only if some client has connected, so it's
logical that if this client tries to connect and knows
that it's closed the port doesn't kept alive anymore time
(I've read that the cause of this openned behaviour is to
give time for clients to know the closed state...).
Any way it's a "solution". So programatically I can do
that when the client gets a communication exception it
tries to reopen it in order to send this "signal" to the
actual port...

buff...this brings me so many C programming remembers!

Anyway, thank you Patrick.

-----Original Message-----
In article <a4****************************@phx.gbl>,
an*******@discussions.microsoft.com says...

First of all, thanks for your reply Patrick.
No problem.

I saw a similar solution somewhere but I tried waiting and more than 20 minutes after, nothing happened.
Anyway, I'm using it on a server application being full of different communication channels, so is not a good
solution that a remote process waits for the channel to be restarted an unknown time after a reconfiguration...

Should this be the only solution?, any other way?

SOAP and remoting are not my strong points. I looked

through the docsan HttpChannel does have a "StopListening" method. Perhaps you couldtry calling that before unregistering the channel.

In fact, maybe you could use the StopListening/StartListening instead ofunregistering and then re-registering the channel?

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele
.