It didn't to me, but I've never done RPC programming on Windows; only SunRPC on UNIX and UNIX-like operating systems. SunRPC is extremely resilient. I would hope Windows RPC is as well.
I would presume that that is the DCOM "method" he is referring to. But I don't know that. From: Brian Desmond [mailto:[email protected]] Sent: Thursday, May 17, 2012 9:47 PM To: NT System Admin Issues Subject: RE: TCP/IP stack reset That answer also sounds kind of BS to me. I'm not sure it makes technical sense all the way through. Thanks, Brian Desmond [email protected]<mailto:[email protected]> w - 312.625.1438 | c - 312.731.3132 From: Michael B. Smith [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Thursday, May 17, 2012 12:34 PM To: NT System Admin Issues Subject: RE: TCP/IP stack reset Sounds like a poorly implemented solution. From: Steve Ens [mailto:[email protected]] Sent: Thursday, May 17, 2012 12:20 PM To: NT System Admin Issues Subject: Re: TCP/IP stack reset This was his reply... In windows there is only one TCP/IP stack even if a server (or workstation) has multiple NIC cards in it. Therefore the reset of ANY NIC card on a windows computer causes the TCP/IP stack on the computer to reset. The problem is that BroadView uses two communications methods. One, the newer one, does not care or is bothered by the stack resets. Unfortunately the other method, the older one, is based on DCOM (a Microsoft technology) which is sensitive to a TCP/IP stack reset. When a reset happens it effectively breaks that part of BroadView. Thus some parts of BroadView (like form operations) continue after a TCP/IP stack reset, but other parts are broken and can only be fixed by restarting BroadView and can cause the BroadView application server to outright crash. So, if the NIC on the server was going bad and kept resetting it would break BroadView. If the switch port that the server is connected to resets, it would cause the stack to reset and again break BroadView. If the cable between the server and the switch is failing it can cause the stack to reset and again, BroadView would break. On Thu, May 17, 2012 at 11:03 AM, Daniel Chenault <[email protected]<mailto:[email protected]>> wrote: If the stack is resetting than it is dropping all current connections. This would be evident in the trace by workstationA sending a packet to ServerA with a response of RST. Following that would be the standard 3-way TCP handshake. I question the robustness of an app that cannot gracefully handle a reset from another layer. I also question why the stack would be resetting frequently enough to be an issue. Resetting a specific connection, sure, but the whole stack? Dubious allegation. Check the trace. Daniel Chenault [email protected]<mailto:[email protected]> [Description: Description: cid:[email protected]] From: Steve Ens [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, May 17, 2012 10:55 AM To: NT System Admin Issues Subject: TCP/IP stack reset Morning/afternoon all... I have a particular application that is giving me headaches. It is client/server based app that is constantly crashing. The vendor is saying it is a network issue: that the network stack is resetting causing one of the services to crash. I've updates the NIC drivers, the HP team drivers and checked the switches and even changed the ports on the switch. I've install wireshark, but am having some difficulty interpreting the capture logs. Any ideas on what to look for would be greatly appreciated. Thanks ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
<<inline: image001.jpg>>
