Events lose connection to localhost

Posts to several groups have yielded no answers yet. Perhaps this one has a
more experienced readership. :,)

Situation: (1) Application subscribes to events generated by a service, via
Remoting and an event wrapper. Both are on the same machine. (2) LAN cable
is disconnected from the machine. (3) App receives no more events! However,
the remoting proxy is still active and the application can invoke methods in
the service. The service reports an exception that "the connection has been
forcibly closed" when it tries to raise the event to the app.

Modified Situation: (1) LAN cable is disconnected from the machine. (2)
Application starts and subscribes as before. (3) LAN cable is connected. (4)
LAN cable is disconnected. (5) NO PROBLEMS!

For obvious reasons, having the user disconnect the LAN while they start the
application is not an acceptable procedure. What can be done?

"John W." <JohnW (AT) discussions (DOT) microsoft.com> wrote

Posts to several groups have yielded no answers yet. Perhaps this one has
a
more experienced readership. :,)

Situation: (1) Application subscribes to events generated by a service,
via
Remoting and an event wrapper. Both are on the same machine. (2) LAN
cable
is disconnected from the machine. (3) App receives no more events!
However,
the remoting proxy is still active and the application can invoke methods
in
the service. The service reports an exception that "the connection has
been
forcibly closed" when it tries to raise the event to the app.

Modified Situation: (1) LAN cable is disconnected from the machine. (2)
Application starts and subscribes as before. (3) LAN cable is connected.
(4)
LAN cable is disconnected. (5) NO PROBLEMS!

For obvious reasons, having the user disconnect the LAN while they start
the
application is not an acceptable procedure. What can be done?

Is this on XP? The TCP stack isn't loaded if you don't have a cable
connected for some gawd awful reason even if you have a network card.

Since you are on the local PC, you can use the IpcClient/Server channels OR
you can install (i think available on xp sp 2 or later, but maybe some other
ones) the "loopback" network driver from add/remove programs.

I think there's a KB article out there about this issue.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

"Doug Semler" <dougsemler (AT) gmail (DOT) com> wrote

Since you are on the local PC, you can use the IpcClient/Server channels
OR you can install (i think available on xp sp 2 or later, but maybe some
other ones) the "loopback" network driver from add/remove programs.

Add hardware that is.... Install Manually...Network
Adapters...Microsoft...Microsoft Loopback Adapter

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

Yes, it is XP Pro.
If there is a KB article, it's not keyed under any of the terms I used to
search
for it. However, your mention of the Loopback Adapter sent me down some
new paths that hinted there may be something there. I will try it on Monday
(10/1) and let you know what happens.

"Doug Semler" wrote:

"John W." <JohnW (AT) discussions (DOT) microsoft.com> wrote in message
news:FD23AB78-FF72-4F98-8546-ECDE6A434D68 (AT) microsoft (DOT) com...
Situation: (1) Application subscribes to events generated by a service, via
Remoting and an event wrapper. Both are on the same machine. (2) LAN
cable is disconnected from the machine. (3) App receives no more events!
However, the remoting proxy is still active and the application can invoke
methods in the service. The service reports an exception that "the
connection has been forcibly closed" when it tries to raise the event
to the app.

Modified Situation: (1) LAN cable is disconnected from the machine.
(2) Application starts and subscribes as before. (3) LAN cable is
connected. (4) LAN cable is disconnected. (5) NO PROBLEMS!

For obvious reasons, having the user disconnect the LAN while they
start the application is not an acceptable procedure. What can be
done?


Is this on XP? The TCP stack isn't loaded if you don't have a cable
connected for some gawd awful reason even if you have a network card.

Since you are on the local PC, you can use the IpcClient/Server channels OR
you can install (i think available on xp sp 2 or later, but maybe some other
ones) the "loopback" network driver from add/remove programs.

I think there's a KB article out there about this issue.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

Found a time slot to check it today (never would have found it without your
updated directions!), and...
Rats! That wasn't the solution.

"Doug Semler" wrote:

"Doug Semler" <dougsemler (AT) gmail (DOT) com> wrote in message
news:eVJHJcfAIHA.5960 (AT) TK2MSFTNGP05 (DOT) phx.gbl...

Since you are on the local PC, you can use the IpcClient/Server channels
OR you can install (i think available on xp sp 2 or later, but maybe some
other ones) the "loopback" network driver from add/remove programs.

Add hardware that is.... Install Manually...Network
Adapters...Microsoft...Microsoft Loopback Adapter

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

"John W." <JohnW (AT) discussions (DOT) microsoft.com> wrote

Found a time slot to check it today (never would have found it without
your
updated directions!), and...
Rats! That wasn't the solution.

Sorry...Google lookup DisableDHCPMediaSense...and follow the directions
there. if that doesn't work, i'd suggest switching to IPCServer/Client
communication when the remoting is on the local system (that way you don't
require the TCP/IP stack....and it's much faster)



--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

Can't do the disable thing. This connection is one of several to identical
services on other machines. I need to detect loss of connectivity to the
other servers, and recovery of those connections occurs flawlessly right now.
I just need the localhost connection to either break both links (events and
remoting proxy) or leave both links intact instead of breaking just one and
leaving the one I use to detect the break.

IPC may be the solution path, but there's a bunch of learning to be done
before I can go there, and then the localhost connection (and service?)
becomes unique. Ugh.

"Doug Semler" wrote:

Sorry...Google lookup DisableDHCPMediaSense...and follow the directions
there. if that doesn't work, i'd suggest switching to IPCServer/Client
communication when the remoting is on the local system (that way you don't
require the TCP/IP stack....and it's much faster)

--
Doug Semler, MCPD

"John W." <JohnW (AT) discussions (DOT) microsoft.com> wrote

Can't do the disable thing. This connection is one of several to
identical
services on other machines. I need to detect loss of connectivity to the
other servers, and recovery of those connections occurs flawlessly right
now.
I just need the localhost connection to either break both links (events
and
remoting proxy) or leave both links intact instead of breaking just one
and
leaving the one I use to detect the break.

IPC may be the solution path, but there's a bunch of learning to be done
before I can go there, and then the localhost connection (and service?)
becomes unique. Ugh.

Yeah I know. We actually redesigned our solution at one point to
specficially avoid remoted events.

Ingo Rammer's book has a good demonstration on how to do remoted events if
you haven't already looked into that.

Sorry, I would help you more but I had four teeth pulled today and am a bit
out of it. If I htink of anything else over the weekend i'll post.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

I'm trying to understand IPC for this, but have run into two walls.
(1) I built a mod of the IPC examples that resembles what we do and got it
working in a variety of ways, but when I try to add events I get an error
about something not being "allowed to be serialized at this level." Another
variation dies with "the client doesn't have a sink channel...."
(2) When I change the channel from TCP to IPC in my real apps, I get "Access
denied" errors when the client app tries to connect with the server object.
I suspect this is a higher-up cousin of the first of the above errors.

I'm beginning to see why you abandoned the events. Wish I could.

A MS support person suggested adding "bindto='127.0.0.1' " on the tcp
channel creation, but that didn't help either. I smell an OS bug emerging.

"Doug Semler" wrote:

Yeah I know. We actually redesigned our solution at one point to
specficially avoid remoted events.

Ingo Rammer's book has a good demonstration on how to do remoted events if
you haven't already looked into that.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

"John W." <JohnW (AT) discussions (DOT) microsoft.com> wrote

I'm trying to understand IPC for this, but have run into two walls.
(1) I built a mod of the IPC examples that resembles what we do and got it
working in a variety of ways, but when I try to add events I get an error
about something not being "allowed to be serialized at this level."
Another
variation dies with "the client doesn't have a sink channel...."
(2) When I change the channel from TCP to IPC in my real apps, I get
"Access
denied" errors when the client app tries to connect with the server
object.
I suspect this is a higher-up cousin of the first of the above errors.

I'm beginning to see why you abandoned the events. Wish I could.

Two things real quick for your own lookup real quick (I'm too buzzed to
respond properly and I may have these properties a little wrong but it could
give you a good starting point)

BinarySerialization (Level?) = Full on both the client AND server level
serialization methods. This gets around type serialization issues.

IPC communications in .NET 2 gives default access. On XP+ that means that
CREATOR OWNER is the only one that is gonna be able to write to it. you
can get around this by either specifying an authenticationLevel attribute
name (i believe that's the name it may be slightly different....MSDN has the
right one) to the user group of the IPC access. Or, if you are creating the
IPC server/client by "hand" you should be able to specify the acces group.

Remember, an IPC connection type is implemented as a named pipe, which means
it follows the same DACL rules of named pupes.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?