Thank you, this is helpful. You solution is the most general. It does require two reads for every transaction, since there seems to be escape codes somewhere in each sequence, but it's more robust your way.
Paul Alfille On Fri, Jul 3, 2009 at 6:40 PM, Jerry Scharf<[email protected]> wrote: > Paul, > > I was being a bit dense with my last email. > > You should request the number of bytes you expect. When you scan it, > start looking for FF FA codes. If that shows up, see if the F0 is in the > read buffer. If so, move the char pointer back to where the FF point was > and ask for the rest of the string (expected - FF...F0 bytes.) If the F0 > isn't in the read buffer, start reading byte by byte into a separate > variable looking for F0. Once you find that, then do the move the > pointer and read the rest piece as above. Finally, don't forget to scan > the rest of the strings for more FF FA blocks. It's most sloppy when the > FF is the last character of the initial read buffer... > > You can also scan and remove the patterns FF F1 - FF F9 as these are 2 > byte commands that the transmitter can send at any time. It is also > possible that you could see FF FB xx - FF FE xx 3 byte codes, but this > would be in response to FF FA codes that you would send, so that seems > unlikely. Handling these would be just the same as the FF FA codes above. > > It really is a blast from the past for me. There was a time when I could > decode telnet streams and FTP command streams on a RT passive monitor at > close to typing speed. Life has gotten so much more complex than these > early protocols. > > 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 > ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
