Re: Reading data from a file descriptor

[<tomas@tuxteam.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Nov 16, 2015 at 11:54:33AM +0100, Amirouche Boubekki wrote:
> On 2015-11-13 21:41, Jan Synáček wrote:

[...]

> >I have an open fd to a unix socket and I want to read data from it. I
> >know that the data is going to be only strings, but I don't know the
> >length in advance.
> 
> Do you know a delimiter? maybe it's the null char?
> 
> TCP is stream oriented, it's not structured at this layer into messages
> or segments. You need some knowledge about the byte stream to be able to
> split it into different meaningful piece for the upper layer.

I think I "got" Jan's request, because I've been in a similar
situation before: delimiter is not (yet) part of it. What he's
looking for is an interface à la read(2), meaning "gimme as much
as there is in the queue, up to N bytes, and tell me how much
you gave me". Of course, putting stuff in a byte vector would
be preferable; the only functions I've seen[1] which "do" that
interface are read-string!/partial and write-string/partial
operate on strings, not byte arrays, alas.

> In Python the socket.recv method returns bytestring but still you
> have to parse
> to bytestring to make sure the delimiter is not in the middle of the
> string. What
> I mean is that in theory you might socket.recv the end of an
> application level message
> and the beginning of another using the same call.

Not (yet) about delimiters.

> Otherwise said, the only thing that could make sens for a (recv)
> procedure is
> to return the full content of the inbound network buffer for the
> given socket
> as a bytevector but it will still require work to to make things work...

Exactly, see above. A delimiter, or just feed the thing to an
incremental scanner/parser (e.g. a finite state machine, which
can get its input spoonwise).

> Have a look at the implementation. IMO the solution is to build a
> loop with
> (read-char) [1] looking for the *end char* to stop the loop.

If your application is set up to accept partial buffers of arbitraty
length, it seems a bit wasteful to have a buffered read (which is
definitely beneath `read-char') going through a character-wise
read into a new buffered read...

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZK+Q8ACgkQBcgs9XrR2kaV6QCdFkPPiAZqhyC4knvJroGyq2+m
I0QAnicg8Cz5VL2I9VfWm7GcMLNhvNsM
=dk4d
-----END PGP SIGNATURE-----