Paul, I'm not familiar with your receiver code. I am a little surprised that there is not a telnet interface layer that understands and removes this code before the higher levels ever see it. I have other telnet based interfaces in my control system, and I use the python (my programming language poison) telnet interface layer to handle all this before I see anything.
There is no reason to expect a timeout to occur within a subnegotiation string unless something much bigger happens. The transmission of the subnegotiation burst is not dependent on anything other than the TCP framing and transmission code. It must be transmitted without interruption and thus blocks the telnet data stream. If the device is working and the TCP connection is alive, this will not time out. If either of those break then it doesn't matter. The receiver never needs to respond to negotiation requests once the channel is open. jerry Paul Alfille wrote: > Hmm... at first I was dismayed, since not knowing the length of extra > characters, I have to wait for a timeput after every transaction. I > suspect that the initial handshake will show the extra character > string, and I'll just look for it in every transaction after that. > > Paul > > On Fri, Jul 3, 2009 at 3:52 PM, Jerry > Scharf<[email protected]> wrote: >> Paul, >> >> Bang on target and a great thought. >> >> I dusted out the telnet RFC (I haven't looked at it in a decade or more) >> and the receiver should be able to filter on anything that is FF FA ... >> F0. Brings back old memories. >> >> jerry >> >> Ziggy wrote: >>> The FF fx hex sequences look like telnet IAC sequences to me. In most >>> device servers these can be disabled. It's often called raw mode, >>> transparent mode, or something similar. I'll take a look at the Xport >>> doc later tonight. Maybe the whole extra character problem can be >>> avoided by setting the right config option on the Xport. You don't >>> really want a telnet connection, just a TCP 'pipe'. > > Yes, but changing the configuration options may be more complex than > some users can deal with. I wish the LINK folks had one of these on > line to test against. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Owfs-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
