-----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-----
