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