I wouldn't describe it as a false sense of security. Most seem to know the risks, and I'm sure many have even seen the listener taken just as you describe. The concern is not "other sites" but other systems on the LAN, and it may be the client mirror system that's apt to grab the listener when a process gets started that shouldn't.
>From what you describe, it seems it would be best if all systems used only original mode acks. Probably not a universal solution, even it if is better for TCP. Systems can be very different. Not all situations call for application acks, and in some the application ack comes much later. I've only seen a couple other engines, but I think the 1.6 engine is pretty good all around. You can do just about anything you want with it. And from what I've read about the HLO engine it's pretty good too. I understand it also improves performance, though I believe that was related to relieving disk and process contention. >From what I've seen, the bottleneck is typically not the transport, or even the decoding of the message, it's how the message is processed after it is received. Sometimes its design, say if the system requires processing all inbound ADT serially. Sometimes its poor implementation, I've seen some atrocious interface code. Often it simply costs more to apply the meaning of the message than it does to send it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Woodhouse Sent: Friday, December 16, 2005 6:38 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Setting up HL LOGICAL LINKs problem - Noresponse On Dec 16, 2005, at 2:43 PM, Gary Monger wrote: > Some sites like the single connection. The thought being that > there is less > risk of an inadvertent connection from a test system. > By the same token, another site could "grab" the listener during a restart. But perhaps more to the point, relying on having the port tied up in this way leads to a false sense of security, and is really a misuse of the protocol. You should reject connection attempts from other sites, instead. > What processing is being done by the listener has a lot to do with > performance. Some servers just dump the message to a queue, > processing just > enough of the message to send a commit ack. Some don't even read > the MSH. > That can help, but it doesn't address the basic sources of the performance problem. For one thing, polling a connection by attempting to read can lead to a situation where the receiving TCP keeps shrinking the advertised window, leading to abnormally slow transfers. By the same token, an open connection that is idle, will have to "ramp up", which is not particularly good for short transfers (like messages). Another part of the LLP that doesn't fit well with TCP is the whole scheme of using inbound and outbound links. True, commit acks are sent back on the same link, but the "turn around" is counterproductive. Sending application acks on a separate link is a really bad idea. The reason is that TCP waits for a packet to be ready to go in the reverse direction so that it can "piggy back" a (TCP) acknowledgment on it. When the communication pattern is half duplex (as it is in MLLP), this means no such opportunity arises, and the TCP basically has to time out and finally send an acknowledgment only packet. I understand that MLLP is modeled on the protocol used for serial lines (where full duplex communication is not supported), but it's a poor design for TCP. === Gregory Woodhouse [EMAIL PROTECTED] "We ascribe beauty to that which is simple." --Ralph Waldo Emerson ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
