[Libwebsockets] 回复: 答复: A question about libwebsockets dns resolve

huangkaicheng huangkaicheng at huawei.com
Mon May 25 09:35:58 CEST 2020


Hi,

   [cid:image001.png at 01D632AA.2E050B80]



   there is still something wrong with latest code. Why try to connect 127.0.0.1, 127.0.0.3, 127.0.0.2 time out so quickly?





-----邮件原件-----
发件人: Andy Green [mailto:andy at warmcat.com]
发送时间: 2020年5月22日 15:04
收件人: huangkaicheng <huangkaicheng at huawei.com>; libwebsockets <libwebsockets at ml.libwebsockets.org>
抄送: Chenyake <chenyake at huawei.com>
主题: Re: 回复: [Libwebsockets] 答复: A question about libwebsockets dns resolve







On 5/22/20 7:44 AM, huangkaicheng wrote:

> Hi,

>

>     Have you pushed it to master? It seems that there is no commit about it?



Since it changes what we do in the original commit, and it's master, I just modify the original commit directly



https://libwebsockets.org/git/libwebsockets/commit/minimal-examples/http-client/minimal-http-client-multi?id=c97b68272c6c473bf7f2712da0f3fb870c3c92e0



Theres a note in the README.release-policy.md about how to follow master:





To follow such a branch, git pull is the wrong tool… the starting point of what you currently have may no longer exist remotely due to rearranging the patches there. Instead use a flow like this:



  $ git fetch https://libwebsockets.org/repo/libwebsockets +master:m && git reset --hard m This fetches current remote master into local branch m, and then forces your local checkout to exactly match m. This replaces your checked-out tree including any of your local changes, so stash those first, or use stgit or so to pop them before updating your basis against lws master.





-Andy



> -----邮件原件-----

> 发件人: Andy Green [mailto:andy at warmcat.com]

> 发送时间: 2020年5月22日12:09

> 收件人: huangkaicheng <huangkaicheng at huawei.com<mailto:huangkaicheng at huawei.com>>; libwebsockets

> <libwebsockets at ml.libwebsockets.org<mailto:libwebsockets at ml.libwebsockets.org>>

> 抄送: Chenyake <chenyake at huawei.com<mailto:chenyake at huawei.com>>

> 主题: Re: 答复: 回复:[Libwebsockets] 答复: A question about libwebsockets dns

> resolve

>

> On 5/21/20 2:22 AM, huangkaicheng wrote:

>

>>> If we want that, we need to move the individual connect timeouts lws manages to its own private lws_sul.

>

>> Can you help to move the individual connect timeouts lws manages to its own private lws_sul? Thanks.

>

> I modified the original patch on master to use its own lws_sul for the

> connect timeouts, please give current master a try.

>

> -Andy

>

>>

>

>> -----邮件原件-----

>

>> 发件人: huangkaicheng

>

>> 发送时间: 2020年5月20日14:21

>

>> 收件人: 'andy at warmcat.com' <andy at warmcat.com <mailto:andy at warmcat.com<mailto:andy at warmcat.com%20%3cmailto:andy at warmcat.com>>>;

> libwebsockets

>

>> <libwebsockets at ml.libwebsockets.org

> <mailto:libwebsockets at ml.libwebsockets.org>>

>

>> 抄送: Chenyake <chenyake at huawei.com <mailto:chenyake at huawei.com<mailto:chenyake at huawei.com%20%3cmailto:chenyake at huawei.com>>>

>

>> 主题: 回复:[Libwebsockets] 答复: A question about libwebsockets dns resolve

>

>>

>

>>> "reuse" means I not only set the time, but direct it to use a

>

>>> different callback when it fires... after the connect if you set a wsi timeout it will also set the callback to handle a generic wsi timeout.  So while it's waiting for connect, setting some other wsi timeout is  in conflict with this connect timeout detection stuff.

>

>>

>

>> I understand what you mean, But it seems that in  windows and linux it is different when I test.

>

>>> Why do you want to set an explicit wsi timeout on it when it already

>

>>> now takes care of setting the connect timeout itself?  You're trying to set an overall timeout including all retries?  If we want that, we need to move the individual connect timeouts lws manages to its own private  lws_sul.

>

>>

>

>> Yes, we want to set an overall timeout including all retries. because all tries times is tool long, it is not good.

>

>>

>

>> -----邮件原件-----

>

>> 发件人: andy at warmcat.com<mailto:andy at warmcat.com> <mailto:andy at warmcat.com>

>> [mailto:andy at warmcat.com]

>

>> 发送时间: 2020年5月20日11:37

>

>> 收件人: huangkaicheng <huangkaicheng at huawei.com

> <mailto:huangkaicheng at huawei.com>>; libwebsockets

>

>> <libwebsockets at ml.libwebsockets.org

> <mailto:libwebsockets at ml.libwebsockets.org>>

>

>> 抄送: Chenyake <chenyake at huawei.com <mailto:chenyake at huawei.com<mailto:chenyake at huawei.com%20%3cmailto:chenyake at huawei.com>>>

>

>> 主题: Re: 回复:[Libwebsockets] 答复: A question about libwebsockets dns

>

>> resolve

>

>>

>

>>

>

>>

>

>> On May 20, 2020 3:20:14 AM UTC, huangkaicheng <huangkaicheng at huawei.com <mailto:huangkaicheng at huawei.com<mailto:huangkaicheng at huawei.com%20%3cmailto:huangkaicheng at huawei.com>>> wrote:

>

>>> Hi,

>

>>> I know why because I set timeout

>

>>> "PENDING_TIMEOUT_AWATING_CONNECT_RESPONSE",if I set this time_out

>

>>> like

>

>>> 20 sec. and "schedule wait_time" out will not take effect. If it is

>

>>> confict with  "PENDING_TIMEOUT_AWATING_CONNECT_RESPONSE" in mac?,

>>> but

>

>>> in windows and linux will not?

>

>>

>

>> The way I implemented this connect timeout was to reuse the wsi

>

>> lws_sul that tracks timeout

>

>>

>

>> https://libwebsockets.org/git/libwebsockets/commit?id=918a608552bfe50

>> 0

>

>> 2196715a6d6b3793bfc29f74

>

>>

>

>> "reuse" means I not only set the time, but direct it to use a

>> different callback when it fires... after the connect if you set a

>> wsi timeout it will also set the callback to handle a generic wsi

>> timeout.  So while  it's waiting for connect, setting some other wsi

>> timeout is in

> conflict with this connect timeout detection stuff.

>

>>

>

>> Why do you want to set an explicit wsi timeout on it when it already

>> now takes care of setting the connect timeout itself?  You're trying

>> to set an overall timeout including all retries?  If we want that, we

>> need  to move the individual connect timeouts lws manages to its own

>> private

> lws_sul.

>

>>

>

>> -Andy

>

>>

>

>>>

>

>>>     Huangkaicheng

>

>>>

>

>>>

>

>>> -----邮件原件-----

>

>>> 发件人: Andy Green [mailto:andy at warmcat.com]

>

>>> 发送时间: 2020年5月19日23:09

>

>>> 收件人: huangkaicheng <huangkaicheng at huawei.com

> <mailto:huangkaicheng at huawei.com>>; libwebsockets

>

>>> <libwebsockets at ml.libwebsockets.org

> <mailto:libwebsockets at ml.libwebsockets.org>>

>

>>> 抄送: Chenyake <chenyake at huawei.com <mailto:chenyake at huawei.com<mailto:chenyake at huawei.com%20%3cmailto:chenyake at huawei.com>>>

>

>>> 主题: Re: 答复: 回复:[Libwebsockets] 答复: A question about libwebsockets

>

>>> dns resolve

>

>>>

>

>>>

>

>>>

>

>>> On 5/19/20 3:40 PM, huangkaicheng wrote:

>

>>>> Hi ,

>

>>>>

>

>>>>   In my mac pro , I found that schedule of wait does not take

>

>>> effect

>

>>>> and" lws_client_conn_wait_timeout"  does not trigger when it try to

>

>>>> connect to “127.0.0.1”. I have add some log for you. See more in

>

>>>> attachment. I do not understand why”wait_timeout “is not trigger.

>

>>>> And

>

>>>

>

>>>> I try it with “onevalid.bogus.warmcat.com”. please help to check why.

>

>>> Thanks.

>

>>>

>

>>> Dunno... but... I can usually do something about my code if it has

>

>>> problems.  I can't do anything about your code.

>

>>>

>

>>> I can't reproduce your problem with my code (the minimal example),

>

>>> and I tried it on a real OSX machine as you described.

>

>>>

>

>>> Do you have the same problem on your machine if you put your code on

>

>>> one side, and try to repeat the exact same test I showed thismorning

>

>>> using my minimal example alone?  In other words, does it need your

>

>>> code to see the problem coming, or the problem exists without your code?

>

>>>

>

>>> Also if your test was supposed to be idle, because it's waiting for

>

>>> the connect, it seems to be awful busy going around the event loop.

>

>>> In my test, the logs are completely idle while it waits for the

>

>>> connect timeout.

>

>>>

>

>>> -Andy

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20200525/79644a93/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 107567 bytes
Desc: image001.png
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20200525/79644a93/attachment-0001.png>


More information about the Libwebsockets mailing list