[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reading data from a file descriptor
From: |
tomas |
Subject: |
Re: Reading data from a file descriptor |
Date: |
Tue, 17 Nov 2015 10:53:19 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
-----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-----
- Re: Reading data from a file descriptor, (continued)
- Re: Reading data from a file descriptor, Artyom Poptsov, 2015/11/07
- Re: Reading data from a file descriptor, Artyom Poptsov, 2015/11/07
- Re: Reading data from a file descriptor, Andreas Rottmann, 2015/11/07
- Re: Reading data from a file descriptor, Jan Synáček, 2015/11/09
- Re: Reading data from a file descriptor, Mark H Weaver, 2015/11/13
- Re: Reading data from a file descriptor, Jan Synáček, 2015/11/13
- Re: Reading data from a file descriptor, Thompson, David, 2015/11/13
- Re: Reading data from a file descriptor, Jan Synáček, 2015/11/16
- Re: Reading data from a file descriptor, Thompson, David, 2015/11/16
- Re: Reading data from a file descriptor, Amirouche Boubekki, 2015/11/16
- Re: Reading data from a file descriptor,
tomas <=
- Re: Reading data from a file descriptor, Chris Vine, 2015/11/17
- Re: Reading data from a file descriptor, tomas, 2015/11/17
- Re: Reading data from a file descriptor, Chris Vine, 2015/11/17
- Re: Reading data from a file descriptor, tomas, 2015/11/17
- Re: Reading data from a file descriptor, Jan Synáček, 2015/11/18
- Re: Reading data from a file descriptor, tomas, 2015/11/16
- Re: Reading data from a file descriptor, Andreas Rottmann, 2015/11/23
- Re: Reading data from a file descriptor, tomas, 2015/11/24