Sounds like "if anything bad happens, Broadview breaks" which can be translated to "Broadview is not capable of handling an error condition gracefully." If Broadview uses two communication methods and the newer one is more robust and able to handle errors gracefully, why in the world is it using the older method which does not do so? Stuff happens, things reset, bad packets occur, the moon is eclipsed by the sun... on and on it is not a perfect world nor is computing perfect. An app that cannot handle an error state gracefully is, by definition, not robust. Pointing fingers does not change this.
That's just my opinion. I could be wrong. Daniel Chenault [email protected] [Description: Description: cid:[email protected]] From: Steve Ens [mailto:[email protected]] Sent: Thursday, May 17, 2012 11:20 AM 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] with the body: unsubscribe ntsysadmin
<<inline: image001.jpg>>
