请问下,考虑支持unix套接字吗.

[mt21625457]

No description provided.

[qicosmos]

可以支持，但我需要搞清楚这是个啥场景，看看是不是有必要。说一下为什么需要吧。

[mt21625457]

可以支持，但我需要搞清楚这是个啥场景，看看是不是有必要。说一下为什么需要吧。

主要指作为接入podman unix套接字 和 同服务器组件之间的通信的 基础框架. unix套接字 比 127回环地址效率高很多.

[Jackarain]

看到这个问题, 顺便翻看了一下部分代码, 提一个建议, 其中:

cinatra/include/cinatra/coro_http_client.hpp

Line 1170 in c9bec30

struct socket_t {

项目中对 socket 抽象不是很优雅, 且到处充满了 CINATRA_ENABLE_SSL 宏判断.

一个建议, 可以考虑使用 variant 将 ssl_stream 与 tcp::socket 又或者 unix domain socket 抽象到一个如名为 socket_type 类型中, 将其不同之处, 就可以很好的控制在 socket_type 这个类型的小范围内, 使用时依据业务逻辑需要, 判断初始化为具体的类型(如: 访问的是 https 则根据 ssl_stream 类型来初始化).

[qicosmos]

CINATRA_ENABLE_SSL 宏是必要的，是为了让用户能第一次就能把cinatra run起来。

很多用户都没有安装openssl，不用宏，然后项目里引用openssl 头文件会编译报错。

通过宏来避免这个问题。

[qicosmos]

如果要支持管道的话socket 那里需要再泛化一下，支持管道与否，现在还没列入开发计划

[Jackarain]

CINATRA_ENABLE_SSL 宏是必要的，是为了让用户能第一次就能把cinatra run起来。

很多用户都没有安装openssl，不用宏，然后项目里引用openssl 头文件会编译报错。

通过宏来避免这个问题。

看起来你并没有理解我的意思, 很抱歉可能是我表达的不是很好.

我的意思是 c++ 项目中不应该在业务代码中充满像这些条件判断这种设计, CINATRA_ENABLE_SSL 可以用在如 socket_type 中判断, 但是使用到 socket_type 的地方, 比如收发数据的地方, 不应该再使用类似这种宏来判断是 ssl_stream 还是普通 tcp::socket

通常这种场景是通过类似:
using socket_type = boost::variant2::variant<ssl_stream, tcp::socket>;
或者

template<typename... T>
class socket_type : public boost::variant2::variant<T...>
{ ... };

就是这个意思, 这样无论是什么类型的 socket 都可以较方便的抽象起来, 不会因为 socket 类型的不同而污染到使用的地方, 在没有安装 openssl 的情况下, 对于 CINATRA_ENABLE_SSL 宏判断, 可以在 class socket_type 中完成差异处理.

当然上面这一切都建议, 具体还请斟酌.

[qicosmos]

谢谢你的解释，我理解了你的意思，但我不觉得variant 是一个好的设计，它让问题变得复杂，而且也会带来额外的性能损耗。应该可以有一个更好的设计。

[mt21625457]

我将acceptor 抽象一下, 就可以支持了

[qicosmos]

要不你提个pr吧 @mt21625457

[mt21625457]

要不你提个pr吧 @mt21625457

好的。我这边公司测试完了, 没有问题了,我提pr