On Fri, 16 Jun 2006 00:00:00 GMT, Ted MacNEIL <[EMAIL PROTECTED]> wrote:
>... >We have no guaranteed delivery! Period! >And, the only change was SNA to TCP/IP. >... But that doesn't mean TCP/IP is at fault. By the description elsewhere in this thread, this could be an interaction between Delayed Acks and the Nagle algorithm - a configuration/tuning issue. And in any case, the data does eventually get delivered ... but probably not soon enough for your application and/or Tn3270 client and server to cope with. >>>If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. > TCP/IP and SNA had very different design criteria with very different definitions of "robust". To TCP, "robust" means the packet will eventually get from source to destination even if the packet has to be routed via Mars and is routed from hop to hop for a week. To SNA "robust" means that a frame is rapidly set from hop to hop along a predefined path, and if that cannot be guaranteed the session will be broken so it can be re-established across another predefined route. (APPN with HPR does a pretty good job of taking the best characteristics of both SNA and TCP/IP.) >From a perfomance standpoint, both will fail miserably if incorrectly defined, but the SNA failure is likely to hard and permanent until corrected. When it is working it works consistantly within quite tight limits. A TCP/IP network doesn't permanently fail, but may have terrible performance characteristics. Application written expecting SNA performance characteristics may very well not work well in a TCP/IP environment. This is NOT the fault of TCP/IP. > >>That sounds like a problem with the Tn3270 client, or some kind of incompatability between the Tn3270 client and server, or some such. > >I can reproduce the problem manually (with 5 minutes of effort). >It has to do with the lack of think time. >Just pound a PFKey until the host barfs. >It happens with: >RUMBA >ATTACHMATE >Hummingbird, >and at least three different web-clients: >2 in JAVA >and on in ACTIVEx. > That doesn't eliminate the possibility of Delay Ack being specified at the server. >... >The packet drops (not always the same one), but with no think time the desktop is sending the data too fast. >... >The packets are one PFKey. > That definitely sonds like the Nagle / Delay Ack issue. It's more likely to happen with short packets. But I suspect there are other possible configuration causes. Or a bug in the server or TCP/IP stack. > >>I happen to be an SNA bigot and have no love for TCP/IP, but don't like seeing bogus arguments against TCP/IP. > >It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG Canada in April. >Even with my poor grasp of terminology, she knew what the issue was. >Something about NAGLE (spelling?) and host settle-time. > And that is not a poor design in TCP/IP; it's a configuration issue. You can cause probles for SNA with incorrect configurations - they just tend to create harder errors and get fixed sooner. > >>Crying "wolf" helps nobody. > >I am not crying wolf. >Also, I was not asking for help here. >I was just pointing out that TCP/IP sucks, is a weak protocol and is going to take over the market. > I contend that blaiming TCP/IP rather than the configuration is crying wolf. (And my griping about running SNA-designed applications in a TCP/IP environment is crying over spilled milk. We're both guilty.) And I contend that TCP/IP does not suck; that is is actually a pretty robust protocol. But it is radically different than SNA, designed for a very different communication environment (dirty, slow lines), and designed for a completely different goal (delivery of military and governmental communications after nuclear war has disrupted the communication grid vs delivery of commercial data across a well maintained private communication network). Pat O'Keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
