Why gen_tcp socket closes in binary mode, but keeps open in list mode?

Aetherus

I wrote a GenServer that wraps a gen_tcp socket and does some long running tasks involving reading and writing on the socket.

defmodule MyClient do
  use GenServer

  @impl true
  def init(_) do
    {:ok, nil, {:continue, :connect}}
  end

  @impl true
  def handle_continue(:connect, _) do
    {:ok, socket} = :gen_tcp.connect(@ip, @port, [
      mode: :binary,  # <-- NOTICE THIS CONFIG
      packet: 0,
      keepalive: true,
      active: false,
      reuseaddr: true,
      send_timeout: 5000,
      send_timeout_close: true
    ])
    send(self(), :work)
    {:noreply, socket}
  end

  @impl true
  def handle_info(:work, socket) do
    {:ok, data} = :gen_tcp.recv(socket, 4)  # <-- The problematic line
    ...
    {:noreply, socket}
  end
end

When I set the mode to :list, it works fine.

When I set the mode to :binary, the line :gen_tcp.recv always returns {:error, :closed}. I wonder why. Did I messed up the configuration?

17 comments

#gen_tcp

0 1924 17

2020-08-07 12:43:26 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

ityonemo

“Argument Length is only meaningful when the socket is in raw mode and denotes the number of bytes to read. If Length is 0, all available bytes are returned. If Length > 0…”

your socket isn’t in raw mode! You may want to consider just passing length 0, otherwise whatever is incoming is going to cause a problem.

Post #1

Aetherus

I’ve tried packet: :raw, but still no luck.

Post #2

ityonemo

are you trying to read out 4 bytes that is going to tell you how many more bytes are coming in the packet? There’s a special mode for that. let me see if I can find that. (I think you generally don’t want to be using raw).

Post #3

Aetherus

Yes and no. The actual packet size is in the 3rd and 4th byte, in little endian (I just have no right to change the protocol )

By the way, the first 2 bytes is a fixed magic number <<0x68, 0x16>>.

Post #4

ityonemo

I would say pass 0 and use pattern matching to trim the binary down to the size you care about. I don’t know what the BEAM does about malicious packets that are too long…

Post #5

Aetherus

Sadly, there’s no EOF. The sizes of the packets vary. All multi-byte numbers are in little endian. And there’s a damn footer that contains a checksum!! I would definitely trash this stupid protocol and implement a standard one, only if I could. At the moment, my only hope is the raw mode.

Post #6

ityonemo

that’s okay, the beam will reconstitute the packets with appropriate boundaries as sent over TCP, so unless the protocol is doing something really wild and smushing packets together in strange ways, your recv result in should be matchable to {:ok, <<0x66, 0x16, length::16, result::binary-size(length)>>} (with total length length + 4)

Post #7

ityonemo

oh you might need to do an endianness check on the length match.

Post #8

Aetherus

That’s not an option, either. The socket should be always open (unless something unexpected happens), and over time, there’ll be indefinitely many reads and writes on it.

Post #9