But - self sync enables flexibility in data packet sizes, without being prone to stuffing. I use the term stuffing here to denote a kind of network malicious attack.
Had I used prefix-length encoding then an attacker could shove a packet with an enormous size and cause DOS by overwhelming my system resources. Self-sync can prevent that by looking only for the magic separators at known locations. > On Dec 17, 2025, at 08:30, David McClain <[email protected]> > wrote: > > IIRC, the self-sync data format was actually invented to help with read-back > of log files which might get clobbered in random locations. TCP/IP is > actually error-free transmission in its own right, and you shouldn’t ever see > clobbered data arriving. The only error you should see, at the application > level, is a timeout for failure to transmit successfully. > > So self-sync format is probably redundant in socket streams... > >> On Dec 17, 2025, at 08:23, David McClain <[email protected]> >> wrote: >> >> I’ll have to review Paul Phuong’s self-sync protocol to be sure. In my >> system with self-sync encoding, I do believe that there is a special >> sequence of octets that indicate a boundary between data packets. But inside >> the packets is also a length count and checksum, to tell you what to expect. >> >> But overall, with self-sync encoding you don’t depend on receiving a prefix >> count. You simply look for a magic sequence of octets in the stream, >> whenever they arrive. No assumptions are made on segments being read. You >> simply read what is available (for the asynchronous case) and look to see >> (with a state machine) whether the magic octet sequence has been seen. >> >>> On Dec 17, 2025, at 08:17, David McClain <[email protected]> >>> wrote: >>> >>> Well it sounds, from the comments made by you and me, that the key is to >>> send a prefix length in some fixed number of octets, which then describes >>> how many data octets to expect in your next read. >>> >>> The process only secondarily depends on asynchronous/synchronous behavior. >>> You really should block, somewhere, until you receive the proper number of >>> bytes, or generate a timeout error on missing data. And the prefix length >>> (which itself has a known length) tells you what to expect. >>> >>> >>>> On Dec 17, 2025, at 08:11, Marco Antoniotti <[email protected]> >>>> wrote: >>>> >>>> Thank you... >>>> >>>> I am aware of the implementation dependent solutions regarding networking. >>>> >>>> However, if you stick to USOCKET, would it be better to switch to an >>>> explicit loop, or is there some other incantation you could use to avoid >>>> the hanging read? >>>> >>>> Thanks >>>> >>>> Marco >>>> >>>> >>>> On Wed, Dec 17, 2025 at 3:11 PM David McClain >>>> <[email protected] <mailto:[email protected]>> >>>> wrote: >>>>> It sounds like you are using TCP/IP (the streaming protocol) vs UDP? >>>>> >>>>> I have had tremendous success using the LW Asynchronous Socket interface >>>>> for socket streams (TCP/IP). Size of sent phrases seems to make no >>>>> difference to its performance. My transfers have arbitrary sizes and have >>>>> no predictable length. >>>>> >>>>> I do use a self-synchronizing encoding (Phuang) across the wire, and I >>>>> think that ultimately becomes a length-prefix followed by data octets. >>>>> And these packets come in a variety of sizes. >>>>> >>>>> >>>>> >>>>> > On Dec 17, 2025, at 01:01, Marco Antoniotti <[email protected] >>>>> > <mailto:[email protected]>> wrote: >>>>> > >>>>> > Hi >>>>> > >>>>> > I am reading from a uosocket:stream-usocket. My sequence is 100 octets >>>>> > long, but I know the other party is sending UP TO 100 octets. >>>>> > >>>>> > If the other party sends less than 100 octets, >>>>> > read-sequence/usocket-stream (at least the version on LW) hangs. >>>>> > >>>>> > Should I just do a loop, checking for the "end marker"? >>>>> > >>>>> > Thanks >>>>> > >>>>> > All the best >>>>> > >>>>> > -- >>>>> > Marco Antoniotti >>>>> >>>> >>>> >>>> >>>> -- >>>> Marco Antoniotti, Professor, Director tel. +39 - 02 64 48 79 01 >>>> DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it >>>> <http://dcb.disco.unimib.it/> >>>> Viale Sarca 336 >>>> I-20126 Milan (MI) ITALY >>>> >>>> REGAINS: https://regains.disco.unimib.it/ >>> >> >
