| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2781.1 | More background, please | XHOST::STUTZMAN | | Thu Feb 20 1997 10:20 | 8 |
| Please specify DmQ version, OS and network transports for:
non-reachable node
node on which non-reachable node is being monitored
Additionally, is the node loss being tracked by AVAIL/UNAVAIL,
the DmQ monitor and/or the link tracking provided by the
link connected/lost msg-based API?
|
| 2781.2 | Speed up timeout detect when attaching | GVA05::GUY | | Fri Feb 21 1997 05:11 | 18 |
|
> Please specify DmQ version, OS and network transports for:
> non-reachable node
> node on which non-reachable node is being monitored
DMQ3.2
WNT 3.51
dec chip 2.1040
> Additionally, is the node loss being tracked by AVAIL/UNAVAIL,
> the DmQ monitor and/or the link tracking provided by the
> link connected/lost msg-based API?
They claim they can use AVAIL/UNAVAIL, but they would like if there is a way
to speed up the process of node unavailable during the first DMQ attachment.
Jean-Paul.
|
| 2781.3 | | XHOST::SJZ | Rocking the Messaging Desktop ! | Fri Feb 21 1997 09:26 | 10 |
|
you say you get a timeout status back in 50 seconds ? where
are you getting that ? Is this the result of a put operation ?
have they registered for LINK_NOTIFY ? what is it that they
are currently using ? How is the connection being broken (I
assume that they are forcing the link down condition, by
shutting down the remote group ? or disconnecting the ma-
chine from the network ?)
_sjz.
|
| 2781.4 | Timeout on PAMS attach | GVA05::GUY | | Fri Feb 21 1997 11:18 | 3 |
| They get this after the PAMS attach.
Jean-Paul.
|
| 2781.5 | | XHOST::SJZ | Rocking the Messaging Desktop ! | Fri Feb 21 1997 12:11 | 9 |
|
what does that mean "after the PAMS attach." ? they make what
call and it returns what status ? they send what message and
receive what message in return ?
prior to V4.0, pams_attach_q does not return PAMS__TIMEOUT on
any of the non-VMS platforms.
_sjz.
|
| 2781.6 | NO network detection ? | GVA05::GUY | | Fri Feb 28 1997 05:35 | 12 |
| Actually the customer doesn't experience PAMS_TIMEOUT, he is not able to give
me the exact status he is getting, he thought maybe - 246 but is not sure.
He would like to know why DECmessageQ "takes so long time to see that the
network is down".
Is it possible to tell him a little more about the strategy DMQ uses to
detect network presence.
Thanks
Jean-Paul
|
| 2781.7 | DmQ detects network link loss... | KLOVIA::MICHELSEN | DECmessageQ Engineering | Fri Feb 28 1997 07:36 | 11 |
| re: .6
...using two mechanisms: 1) transport layer errors that are returned to the Link
Drivers and a periodic ping of the link. Therefore, if the underlying network
fails to deliver a timely notification of link loss the fall back is a ping
timeout. Please note that the ping timeout can't be too short or the Link
Drivers will get false readings of link loss when the network is temporarily
congested. To me 50 seconds is reasonable for a ping timeout to occur.
Marty
|
| 2781.8 | Timeout algorithm ? | GVA05::GUY | | Tue Mar 04 1997 12:36 | 3 |
| Thanks a lot for this info, I pass it to the customer.
Jean-Paul.
|