TCP server stops streaming; bug or intentional? #33
Comments
|
Hi Mike
This way works fine together with OpenCPN that open a connection,
receive the messages and then close the connection.
Would not be difficult to make it work the way you expect (that is
very reasonable way), but I don't know if would worth to do it.
Best regards, David
…On Mon, Jan 25, 2021 at 10:59 PM mike w ***@***.***> wrote:
Hi there! I have what may be a silly question about the intended usage of the TCP listener (./rtl_ais -T)
When I run rtl_ais in this mode, and connect a new client to the host and port (eg telnet localhost 10110), the client receives a burst of buffered messages, then nothing further. Sending a character from the client causes the connection to be closed.
What I'd expect: The client receives buffered messages, and continues to receive all newly-parsed messages, until either side terminates the connection.
Taking a look at docs and code, I can't quite see anything I'm doing wrong, so I'm thinking this is either intentional or perhaps just disused. Before I prep a PR, can you share any insight? Thanks for maintaining this!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Hey David - Thanks very much for the fast reply! That makes sense now; OpenCPN is the main client, and it sounds like it is perfectly functional repeatedly connecting. I'm going to prepare a patch that can keep the connection open, and will send it your way. I'll do so in a way which avoids breaking existing applications like this; perhaps a command line flag for "keep TCP connection open". FYI: This mode of operation would make rtl_ais work like similar applications that exist in the ADS-B (plane tracking) world: dump1090 and readsb/readsb-proto being the most popular. I am building a web application that can visualize data from both (airdash), so it will be great to support ais similarly. Cheers! |
When giving the `-T` flag, historical behavior is that the previously received, buffered messages are streamed to the client, and then no more. The socket is kept open until either the client closes it, or until the client sends any data, at which point the client is disconnected. When the `-k` flag is given in addition to the `-T` flag, an alternative behavior is now implemented: As new messages are decoded, they are sent to any attached clients in realtime. The client does not need to disconnect to continue receiving updates. Closes dgiardini#33
|
Just a short update: I've got this feature implemented now, in my branch here: mik3y@8507fbc . It is implemented as an opt-in feature ( I'll be giving it some time testing, then will PR here. Cheers! |
When giving the `-T` flag, historical behavior is that the previously received, buffered messages are streamed to the client, and then no more. The socket is kept open until either the client closes it, or until the client sends any data, at which point the client is disconnected. When the `-k` flag is given in addition to the `-T` flag, an alternative behavior is now implemented: As new messages are decoded, they are sent to any attached clients in realtime. The client does not need to disconnect to continue receiving updates. Closes dgiardini#33
Hi there! I have what may be a silly question about the intended usage of the TCP listener (
./rtl_ais -T)When I run
rtl_aisin this mode, and connect a new client to the host and port (egtelnet localhost 10110), the client receives a burst of buffered messages, then nothing further. Sending a character from the client causes the connection to be closed.What I'd expect: The client receives buffered messages, and continues to receive all newly-parsed messages, until either side terminates the connection.
Taking a look at docs and code, I can't quite see anything I'm doing wrong, so I'm thinking this is either intentional or perhaps just disused. Before I prep a PR, can you share any insight? Thanks for maintaining this!
The text was updated successfully, but these errors were encountered: