In my system, using Async LW Sockets, I get fragments delivered in arbitrary sizes. I label each arrival with a sequence number, and send the packet to a receiving collector task, which reassembles the packets in sequence order. So delivery to the collector can be arranged in any order and the bytes of a fragment will still be placed into correct position. I don’t use one-by-one reception. And I honestly don’t know the algorithm being used for reading in the LW Async Socket protocol. But I don’t have to know this either. I process the packet fragments serially, as your code indicates, but I receive a buffer full of octets each time.
On Dec 17, 2025, at 08:58, Marco Antoniotti <marco.antoniotti@unimib.it> wrote:
Ok David,
If you are saying that Phuong's self-sync protocol has "boundaries", then that's my case.
So
(loop for b = (read-byte socket nil nil) while (and b (/= b <special-byte>)) collect b)
And you forget READ-SEQUENCE, Of course, I'd bet that ACL READ-VECTOR does the same under the hood.
Cheers
MA
On Wed, Dec 17, 2025 at 4:44 PM David McClain <dbm@refined-audiometrics.com <mailto:dbm@refined-audiometrics.com>> 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 <dbm@refined-audiometrics.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://dcb.disco.unimib.it/> Viale Sarca 336 I-20126 Milan (MI) ITALY
REGAINS: https://regains.disco.unimib.it/
-- 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/