Невозможно принимать соединения на сокете, при создании сокетов на удаленном узле через RPC в Erlang
Я изо всех сил пытаюсь определить причину для gen_tcp:accept всегда возвращает ответ {error, closed}.
По сути, у меня есть супервизор, который создает сокет прослушивания:
gen_tcp:listen(8081, [binary, {packet, 0}, {active, false}, {reuseaddr, true}]),
Этот сокет затем передается дочернему элементу, который является реализацией поведения gen_server. Затем ребенок принимает соединения на сокете.
accept(ListeningSocket, {ok, Socket}) ->
spawn(fun() -> loop(Socket) end),
accept(ListeningSocket);
accept(_ListeningSocket, {error, Error}) ->
io:format("Unable to listen on socket: ~p.~n", [Error]),
gen_server:call(self(), stop).
accept(ListeningSocket) ->
accept(ListeningSocket, gen_tcp:accept(ListeningSocket)).
loop(Socket) ->
case gen_tcp:recv(Socket, 0) of
{ok, Data} ->
io:format("~p~n", [Data]),
process_request(Data),
gen_tcp:send(Socket, Data),
loop(Socket);
{error, closed} -> ok
end.
Я загружаю двоичные файлы BEAM супервизора и gen_server локально и загружаю их на другой узел (который работает на той же машине) с помощью вызова RPC для кода:load_binary. Затем я выполняю супервизор через вызов RPC, который, в свою очередь, запускает сервер.{Error, closed} всегда возвращается gen_tcp:accept в этом сценарии.
Если я запускаю супервизор и сервер во время входа в оболочку узла, то сервер может принимать соединения без проблем. Это включает в себя 'remsh' для удаленного узла, который не сможет принимать соединения, если бы я ранее RPCed его, чтобы запустить сервер безуспешно.
Кажется, я могу воспроизвести проблему, используя только оболочку:
[Terminal 1]: erl -sname node -setcookie abc -distributed -noshell
[Terminal 2]: erl -sname rpc -setcookie abc:
net_adm:ping('node@verne').
{ok, ListeningSocket} = rpc:call('node@verne', gen_tcp, listen, [8081, [binary, {packet, 0}, {active, true}, {reuseaddr, true}]]).
rpc:call('node@verne', gen_tcp, accept, [ListeningSocket]).
Ответом на окончательный RPC является {error, closed}.
Может ли это быть как-то связано с владением сокетом / портом?
В случае, если это поможет, нет клиентов, ожидающих подключения, и я нигде не устанавливаю время ожидания.
1 ответ
Каждый rpc:call
запускает новый процесс на целевом узле для обработки запроса. В последнем примере ваш первый вызов создает сокет прослушивания в таком процессе, и когда этот процесс умирает в конце вызова rpc, сокет закрывается. Поэтому ваш второй вызов rpc для попытки принять не удастся из-за уже закрытого сокета прослушивания.
Ваш дизайн кажется необычным в нескольких отношениях. Например, это ненормально, когда супервайзеры открывают розетки. Вы также говорите, что ребенок gen_server
пока вы показываете руководство recv
цикл, который, если работать в gen_server
заблокирует это. Вместо этого вы могли бы объяснить, чего вы пытаетесь достичь, и попросить помощи при разработке дизайна, соответствующего вашим целям.