Cant connect to server after disconnect about tacopie

[denbip]

I've just tried to run on 2.01 version - that works fine (dynamic link). The newest version (2.4.3) with static linking does not make more than 1 connection

[denbip]

The newest version with dynamic linking works too. Why you do not use MSG_NOSIGNAL on send function?

[Cylix]

Hi,

I guess you are talking about trying to tcp_client to a remote server (just wanna make sure you are not talking about trying to connect to a tcp_server)?

I just had a try with the latest version 2.4.3, compiling tacopie as a shared and as a static library.
For my testing, I used a custom cpp_redis test but, unfortunately, I was not able to reproduce the issue (I connected/disconnected multiple times without any issue).
My environment is OSX Sierra (10.12.5) with an 8 cores CPU.

Do you have any examples/environment details that you can share with me so that I can try to find a possible root cause?

Concerning MSG_NOSIGNAL, there is no reason I do not use it: that's a good catch!
However, this will technically do not solve the issue you are facing as it just prevents SIGPIPE signal, except if you actually can't reconnect due to a SIGPIPE? Or is it that you try to reconnect but nothing happens?

Thanks a lot for reporting this issue, it helps me to make this library better :)

Best!

[denbip]

I am using tcp_server, and if it shared library all is ok, but when it static I can connect only once, second connection does not work, just nothing happens. I am using debian 8.6.

[denbip]

A little question: why io_service has name poll method but not select? It may confuse because select and poll are different system functions

[Cylix]

Ok, thanks for the precision, I'll try to have a look as soon as possible to see if I can reproduce that.
Do you mind sharing a small code snippet?

For the poll function, originally tacopie was based on poll().
However, poll implementation is buggy and not advised on windows.
So, poll was replaced by select for the windows implementation, and to stay consistent, it was also replaced in the unix implementation.
However, the function wrapping the call to poll/select has kept its name which is now misleading, might be wise to change it.

I'll keep you up to date as soon as I can.

[denbip]

Backing to my problem - I've built a standalone project with static lib - it works fine! It seems something wrong with my real project. What about select on windows and poll on unix?.. select has a limit of connection 1024

[Cylix]

Hi,

I tried with a library I'm working on (netflex) and seems fine.
So apparently the issue is more related to your current use of tacopie from within your project rather than tacopie itself?
Just keep me up to date if you still need me to inspect anything, either in tacopie or in some code snippet :)

Concerning select, I also think I should switch back to poll at some point for the unix part (definitely not windows, sometimes poll simply does not wakeup on windows wtf...).
Right now, tacopie is mostly used by cpp_redis, so mostly the client part: I guess it is not urgent as no-one complained about it for now, but better to make the change ahead.
As I'm working on a http library based on tacopie, I'll make the change during the development of that library.

Let me know if you have any other concerns!

Best :)

[denbip]

Hi! Yes I think something wrong with my project (its very strange, it works with dynamic linking and does not work with static).
How do you think about implementaton autoreconnect on client (on background thread) and transport full message (I mean that messages transported over tcp through buffer, and if message size 1025 when buffer is 1024 it need at least two read callbacks from client, but in real user want to process only one full message)?

[Cylix]

For the auto-reconnect, you can just re-initiate a connection on a fresh socket whenever the connection drops (for example, when you fail to read from the socket) and provide a policy of delay between each retry to avoid flooding the network with connection attempts that mostly fails (retry after 1 second, then 3, then 10, ...).

In the case of reconnection, you should dismiss the temporary buffer that you started to read. When you will reconnect and re-submit the request, the server won't send the missing part of the response but the entire response from the beginning. That's an important point, otherwise, your entire parsing of replies on the client might be broken if you receive an incomplete response.

Concerning message reconstitution in the case of a message larger than your buffer size, it depends on what your program is supposed to do.
If you just provide a basic wrapper around a TCP socket, a bit like the tcp_client of tacopie, then it makes sense to call multiple time the read callback because you are not able to give a sense about the bytes you receive (when does a message start? when does it end?).

But if you implement a client that respect a protocol and that your program only calls the read callback when it has finished to process the reply, then you have two different ways:

• either you store all the bytes you read in a temporary buffer and try to find the ending sequence. Whenever you find the ending sequence, you parse the buffer and call the read callback.
• either you read from the socket and immediately start to partially parse the message from the bytes you get. You keep reading from the socket and parse until you find the ending sequence of your message.

Neither is better than the other in every case: it depends on the protocol you have.
If you have a protocol that is really basic to parse, then the second one might be a good choice because you avoid to keep a huge buffer in memory and parse at the same time (you save some time).
But first one is maybe better if you have a complex protocol that requires you to get the entire buffer to then apply a lexer/parser over it (though I guess it is rarely the case?).

This is exactly what I do for example in my implementation of cpp_redis with a system of builders: every time I read some bytes, I "feed" the current builder (parser) with it. Whenever I reach the ending sequence, the builder notify me that I finished to read the entire server response. This is useful in the case of partial messages, but also in the case of multiple messages received in one read from the socket.
cpp_redis builders.

Similarly, I am also doing the same for another library in development to parse HTTP requests:
netflex parsing.

Concerning the static/dynamic library, that's pretty weird and I don't have any clue why it would work with one but not the other?

Let me know if you have any other questions!

Best

[Cylix]

I'm closing this issue, but feel free to re-open it if necessary.

Best