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 <[email protected]> > 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 <[email protected] > <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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/ >>> >> > > > > -- > 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/
