Support for Unix Domain Sockets

[asfernandes]

Unix Domain Sockets would be a interesting thing for Firebird in mobile (Android & iOS), where applications are confined, since UDS is based in filesystem permissions.

It opens possibility for application to start a Firebird server and connect to it when it can't use embedded, for example: node-firebird-driver-native do not work in react-native, but node-firebird-driver-wire should work.

[mrotteveel]

@asfernandes You haven't implemented it for Windows, while Windows does support Unix Domain Sockets (with some limitations, IIRC). What is the reason to not also add support for it on Windows?

[hvlad]

Looks like server can't listen on both local and inet sockets, correct ?
I.e. this feature is not for the regular usage on desktop/server host, for mobile only ?

[asfernandes]

Looks like server can't listen on both local and inet sockets, correct ? I.e. this feature is not for the regular usage on desktop/server host, for mobile only ?

Firebird configuration is already very limited in this regard. It can't listen in multiple ports or no port, for example.

This PR is not about this.

For the usage scenarios I'm thinking, it would be good to disable TCP/IP when one wants to enable UDS.

[hvlad]

Looks like server can't listen on both local and inet sockets, correct ? I.e. this feature is not for the regular usage on desktop/server host, for mobile only ?

Firebird configuration is already very limited in this regard. It can't listen in multiple ports or no port, for example.

On Windows, Firebird have 2 listeners already, and there were 3, before WNET was removed.

This PR is not about this.

Why not ?

For the usage scenarios I'm thinking, it would be good to disable TCP/IP when one wants to enable UDS.

There is standard way to enable only required listeners, see WinMain() in src\remote\server\os\win32\srvr_w32.cpp

[livius2]

Sorry for the off-topic, but I see that @asfernandes, as a core developer, created both an "issue" and a "PR." Should I also create an "issue+PR" pair if I created a "PR," or will just "PR" suffice? I'd like to know the rules for the future.

[sim1984]

Sorry for the off-topic, but I see that @asfernandes, as a core developer, created both an "issue" and a "PR." Should I also create an "issue+PR" pair if I created a "PR," or will just "PR" suffice? I'd like to know the rules for the future.

This is optional, but it is recommended. If you are interested in your PR Rollup/cube/grouping set, there is already a ticket for this. Simply find it and leave a comment stating that it is implemented in your PR (link).

[asfernandes]

I do think that it's better to create issue when there is a chance to backport/frontport an issue to more than one release. I see no value in issue+PR when something is only for the next version.

[asfernandes]

@asfernandes You haven't implemented it for Windows, while Windows does support Unix Domain Sockets (with some limitations, IIRC). What is the reason to not also add support for it on Windows?

Added now.

[aafemt]

Issues are used for QA and documentation purpose. New feature tests ans Release Notes are written based on them.

[mrotteveel]

@aafemt I look at both issues and PRs if they are tagged with a fix-version.