8000 feat(ip_range): add support for iprange type · Pull Request #1 · mneudert/ecto_ip_range · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feat(ip_range): add support for iprange type #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 23, 2022

Conversation

ghost
Copy link
@ghost ghost commented Jan 10, 2022

I believe the PR is now complete. Please take a look and let's see if we can't get this published into a new version of your lib.

Thanks in advance.

@mneudert
Copy link
Owner

The bit representation for the :iprange type is quite different from the ot 8000 her currently available types.

As I do not want to spoil your fun I hid the details I found in the extension source for that format behind collapsible boxes. Hopefully they are not expanded in any notification mail you might receive so you can decide for yourself how deep you want to dive 😅


ExUnit test to get byte format

You can generate yourself some tests to look at the "wire data":

defmodule EctoIPRange.Postgrex.IPRangeExtensionTest do
  @moduledoc false

  use EctoIPRange.RepoCase, async: true

  alias EctoIPRange.TestSchemaIPRange

  test "select all" do
    Ecto.Adapters.SQL.query!(TestRepo, "INSERT INTO test_schema_ip_range VALUES ('1.2.3.4-2.3.4.5')", [])
    TestRepo.all(TestSchemaIPRange)
  end
end

Encoding and Decoding should always have the same values so only reading yields a more or less useful error message:

     ** (FunctionClauseError) no function clause matching in EctoIPRange.PostgrexTypes."Elixir.EctoIPRange.Postgrex.IPRangeExtension"/6

     The following arguments were given to EctoIPRange.PostgrexTypes."Elixir.EctoIPRange.Postgrex.IPRangeExtension"/6:
     
         # 1
         <<0, 0, 0, 12, 2, 255, 1, 8, 1, 2, 3, 4, 2, 3, 4, 5, 67, 0, 0, 0, 13, 83, 69, 76, 69, 67, 84, 32, 49, 0, 67, 0, 0, 0, 12, 82, 69, 76, 69, 65, 83, 69, 0, 90, 0, 0, 0, 5, 84>>

Everything before the first 67, 0, 0, 0 part should be relevant to the value selected. So the real value to parse would be <<0, 0, 0, 12, 2, 255, 1, 8, 1, 2, 3, 4, 2, 3, 4, 5>> for the test insert and that sort of looks like what I would expect 🤔

IPRange byte format

Looking at the the ip4r source the :ip4r type is using 12 bytes. The first 4 bytes (8::int32) define the number of bytes following and there is always 8 as both upper and lower bound are sent with 4 bytes each.

The :iprange type however sends (and receives) more data:

Looks like we get a 4-byte-size first and then some various options depending on the range itself:

  • one byte PGSQL_AF_INET or PGSQL_AF_INET6
    • looking at the PostgreSQL source I would expect PGSQL_AF_INET = 2 and PGSQL_AF_INET6 = 3 as long as my lookup of AF_INET = 2 was correct
  • one byte for the bitmask (possibly 255 for non-CIDR-values)
  • a static 1 (sent by the database, ignored when the database is receiving)
  • the number of bytes for the range
  • the range itself in various formats
    • one IPv4 for CIDR entries
    • two IPv4 for non-CIDR entries (e.g. 1.2.3.4-2.3.4.5)
    • an IPv6 with 8 bytes if the bitmask is <= 64
    • an IPv6 with 16 bytes if the bitmask is > 64
    • two IPv6 with 32 bytes for arbitrary ranges

@ghost ghost force-pushed the add_support_for_iprange branch 2 times, most recently from 2fa0a94 to 109b227 Compare January 11, 2022 21:30
@ghost ghost marked this pull request as ready for review January 11, 2022 21:31
@ghost ghost force-pushed the add_support_for_iprange branch 3 times, most recently from a4e824c to 5622809 Compare January 12, 2022 15:50
@ghost ghost force-pushed the add_support_for_iprange branch 3 times, most recently from 0b1c7ea to 5e4f49c Compare January 21, 2022 16:10
@ghost ghost force-pushed the add_support_for_iprange branch from 5e4f49c to 7c4d87d Compare January 21, 2022 20:21
@mneudert mneudert merged commit ca6c734 into mneudert:master Jan 23, 2022
@mneudert
Copy link
Owner

❤️ 💚 💙 💛 💜

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
0