aleph

2019-02-06T06:27:47.079100Z

I have a raw tcp protocol, which writes arbitrary length string to the client, and then closes the connection. What is the simplest way to write a client in aleph? Should I read messages from stream until it’s drained and then assemble the whole response? Or is there a better way

mccraigmccraig 2019-02-06T09:17:06.083Z

@romantsopin i would (manifold.stream/reduce conj [] <stream>) the stream into a response buffer... i've not used the aleph tcp client though - do you get chunks on the stream or bytes ? if it's chunks then you would need to concatenate them too, if it's bytes you might want to use a ByteArrayOutputStream or something for more efficient collection (then a vector)

2019-02-06T10:16:33.084Z

Thanks, I will try it. I got bytes on the stream

2019-02-06T11:15:18.088200Z

Also, am I correct, that manifold messages for tcp is just arbitrary slices of tcp stream? And written string could be potentially splitted across different messages? And for websocket every manifold message 1to1 corresponds to websocket message

kachayev 2019-02-06T11:19:32.090700Z

@romantsopin Websocket has framed format for transmitting messages, meaning you can understand where message starts/ends and if it has continuations. This structure is translated into text, binary, close etc frames. If you want to do the same for arbitrary TCP, you need to explicitly tell what the “message” means, otherwise it’s just a raw stream of bytes. For arbitrary length strings it makes sense to write length of the message in known format, like i32 or i64, after that writes the string, goto “begin”.

kachayev 2019-02-06T11:23:00.093300Z

Here you can see example that uses gloss library to encode/decode bytes https://github.com/ztellman/aleph/blob/d35d5bbbb090c31f3f53997ee1e0d68fc7b03044/examples/src/aleph/examples/tcp.clj#L22-L27

2019-02-06T11:25:47.096Z

Yep, thanks, just wanted to make sure I have correct assumptions about manifold abstraction in that case. Unfortunately I can’t control server protocol, it could signals end of the stream only by closing the connection, which is not very convenient. I think something like read until stream is closed (readAllBytes) could be convenient in that particular case..

2019-02-06T11:31:30.098Z

It’s a bit off topic but is this library still supported? I’m asking because repo is archived now

kachayev 2019-02-06T11:35:42.098200Z

I don’t know, I’ve never used it. I’ve just share this as an example of how strings of arbitrary length are typically encoded to be represented as a “message”