full support for UnixDomainSocket backend#1173
Conversation
Coloryr
changed the title
|
Seems to already be in 5.0.0 as was done in #991 ? |
It's look like change the bind, instead of backend support |
|
My modification is for the |
|
My idea is |
| StringBuilder data = new StringBuilder().append(proxyPlayer.getVirtualHost().orElseGet(() -> | ||
| registeredServer.getServerInfo().getAddress()).getHostString()) | ||
| .append('\0') | ||
| StringBuilder data = new StringBuilder().append(getRemoteAddress()) |
There was a problem hiding this comment.
this changes the intended behavior here
There was a problem hiding this comment.
unix socket hoststring like /xxx/xxx is a filename, but inetsocketaddress.getHostString is a ipaddress, because of these two differences, resulting in different behaviors?
| // String playerVhost = | ||
| // proxyPlayer.getVirtualHost().orElseGet(() -> registeredServer.getServerInfo().getAddress()) | ||
| // .getHostString(); | ||
| String playerVhost = getRemoteAddress(); |
| import io.netty.channel.epoll.EpollEventLoopGroup; | ||
| import io.netty.channel.epoll.EpollServerSocketChannel; | ||
| import io.netty.channel.epoll.EpollSocketChannel; | ||
| import io.netty.channel.epoll.EpollDomainSocketChannel; |
There was a problem hiding this comment.
epoll is epoll, we can't just slap it on every single connection type, that is not how that works
|
the referenced pull request to paperMC has been closed; what's the situation here? |
4 participants
Support paper backend with UnixDomainSocket
Is must work with this
refer to #991