weixin_39628271
2020-12-27 11:57 阅读 0

Add support for choosing a process to reply to

The proposal is to distinguish the connection owner and the process that we allow to perform requests and receive stream-related messages (including response). Currently we reject any requests from processes that don't own the connection. It looks as a better approach to store pid of the process that made a request, and redirect all stream-related messages to it.

To achieve that, we could extend a stream data type, adding a new ReplyTo field:

erlang
streams = [] :: [{reference() | websocket_info(), binary(), boolean(), ReplyTo :: pid()}],

We could get its value from request:

erlang
{request, ReplyTo, StreamRef, Method, Path, Headers} ->
    ProtoState2 = Protocol:request(ProtoState,
        StreamRef, Method, Host, Port, Path, Headers, ReplyTo),
    loop(State#state{protocol_state=ProtoState2});
{request, ReplyTo, StreamRef, Method, Path, Headers, Body} ->
    ProtoState2 = Protocol:request(ProtoState,
        StreamRef, Method, Host, Port, Path, Headers, Body, ReplyTo),
    loop(State#state{protocol_state=ProtoState2});

And could use it to send stream-related messages: gun_response, gun_data, gun_push, gun_error

erlang
send_data_if_alive(Data, #http_state{streams=[{StreamRef, _, true, ReplyTo}|_]}, IsFin) ->
    ReplyTo ! {gun_data, self(), StreamRef, IsFin, Data},

A real use case, HTTP connection pool where we have one process holding connection and many processes that want to perform requests.

该提问来源于开源项目:ninenines/gun

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

6条回答 默认 最新

  • weixin_39543478 weixin_39543478 2020-12-27 11:57

    Sounds reasonable. PR welcome. Needs a test though (if current test suites are not really helping, a manual test case would also do).

    点赞 评论 复制链接分享
  • weixin_39628271 weixin_39628271 2020-12-27 11:57

    Will do. Thanks.

    点赞 评论 复制链接分享
  • weixin_39543478 weixin_39543478 2020-12-27 11:57

    It might be good to have two modes, one where the behavior is more or less the same (one process is allowed to make requests), and one where the behavior is like you propose.

    There's probably also some thoughts to be given with regard to Websocket.

    点赞 评论 复制链接分享
  • weixin_39628271 weixin_39628271 2020-12-27 11:57

    Do we really need to restrict requesting processes? What the use case?

    As for WebSockets, we could just keep current implementation. The changes in the PR could be limited by {request, {data, {cancel, messages within the loop/1 handler, I believe.

    点赞 评论 复制链接分享
  • weixin_39543478 weixin_39543478 2020-12-27 11:57

    OK maybe not. I guess those who have the pid can call it, those who don't can't.

    But for Websocket the problem is that if you have 10 processes making requests, and 1 switches to Websocket, all others are going to start receiving errors. I guess it's acceptable but needs to be mentioned at least in the documentation.

    点赞 评论 复制链接分享
  • weixin_39543478 weixin_39543478 2020-12-27 11:57

    Done, thanks!

    点赞 评论 复制链接分享

相关推荐