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 <dbm@refined-audiometrics.com> 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 <marco.antoniotti@unimib.it> 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 <dbm@refined-audiometrics.com> 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 <marco.antoniotti@unimib.it> 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
Viale Sarca 336
I-20126 Milan (MI) ITALY

REGAINS: https://regains.disco.unimib.it/