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/ >> >
