#11671(undetermined:new): enable TCP keepalive socket options
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Type: | enhancement Status: new | Priority: wish Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I would like to kindly request that the TCP keepalive socket option be enabled for TCP sockets in FFmpeg. This would be especially beneficial on Windows, where it is not enabled by default. Without it, it can be difficult to detect inactive or dead connections — for example, after a system suspend/resume event. Thank you very much for your hard work and for considering this request. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by guest): The options handling should be extended in the tcp.c file to support TCP keepalive settings. This new option should then be added to the options in http.c before the call to ffurl_open_whitelist() -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by MasterQuestionable): * cc: MasterQuestionable (added) Comment: ͏ Perhaps not really meaningful: ͏ https://stackoverflow.com/questions/1480236/does-a-tcp-socket- connection-have-a-keep-alive#33927447 https://stackoverflow.com/questions/1480236/does-a-tcp-socket-connection- have-a-keep-alive#comment118529165_33927447 ͏ “After all, asserting that a connection is "alive", only means that you have performed some form of successful communication (past tense!). ͏ But it will be no guarantee that any, or all subsequent communication will succeed (present/future tense). ͏ Therefore there really is no merit in doing this: ͏ At neither the TCP level, nor at the application level. ͏ And you're much better off deciding for: ͏ Either a robust retry-on-failure, or a crash-my-app approach: ͏ Than any other false-sense-of-security, which most people are probably looking for.” -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by guest): I would like to clarify the problem once again because it might not have been completely clear earlier. The ffmpeg client receives data over an HTTP stream but if the stream stops for example due to silenceremove or because a Suspend and Resume occurred and during that time the remote side terminated the connection the client will not detect that the connection has been lost after the Resume and will wait indefinitely. TCP keepalive is designed precisely to handle such situations. Enabling this socket option by default would not cause any disadvantages so simply turning it on would also be a solution. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ “The FFmpeg client receives data over an HTTP stream. ͏ But if the stream stops, for example: due to [https://ffmpeg.org /ffmpeg-filters.html#silenceremove ͏"silenceremove"], or because a Suspend and Resume occurred. ͏ And during that time, the remote side terminated the connection: ͏ The client will not detect that the connection has been lost after the Resume, and will wait indefinitely.” . ͏ You mean the HTTP connection won't automatically timeout..? ͏ Seems like strange behavior. ͏ The common behavior should be: ͏ Timeout if irresponding after certain period; then retry, of max certain times. ͏ I'm unsure of FFmpeg's handling on network streams; which I never counted on. ͏ “FF-* is not the appropriate networking tool. ͏ Though it did support some networking functionalities, for the convenience.” ͏ Anyway I still find the TCP keepalive less reliable. ͏ In particular when used under its original intent: system-wide enabled. ͏ A potential privacy risk. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by guest): What specific privacy risk are you referring to? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Cigaes): MasterQuestionable, the behavior that you describe, “Timeout if irresponding after certain period; then retry, of max certain times”, is precisely the behavior that TCP_KEEPALIVE enables. And AFAIK, there is no such thing as system-wide enabling of TCP keepalive, at least for Linux. And why are you linking to low-quality comments or Java-related questions on stackoverflow? Are you sure you know what this is about? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11671: enable TCP keepalive socket options -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: enhancement | Status: new Priority: wish | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ All linked contents are adequately verified. (specifically for the anchored portion) ͏ Maybe it's somehow tagged Java-related. ͏ But the concept (of TCP keepalive in general) applies generally. ͏ . ͏ The 1st link is primarily intended to provide context, on what TCP keepalive is. ͏ And the anchored answer ([https://stackoverflow.com/questions/1480236/does-a-tcp-socket- connection-have-a-keep-alive#33927447 #33927447]) is clearly not much Java-related. ͏ (more likely a description of TCP keepalive in general) ͏ As for "TCP_KEEPALIVE", I'm unsure if it's certain FFmpeg specific thing. ͏ (rough search of FFmpeg source didn't give much meaningful hint) ͏ But caveat the behavior I describe: ͏ Though similar, it's not exactly TCP keepalive. (fundamentally differs in many details) \\ ͏ On the privacy concerns, it's mostly about the periodic ping alike. ͏ At times can be undesirable. (unintended network traffic) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11671#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg