Skip to content
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

Fix missing "source" field for UDP transport based messages (#5512) #5519

Merged
merged 1 commit into from
Jan 16, 2019

Conversation

bernd
Copy link
Member

@bernd bernd commented Jan 16, 2019

This fixes an issue that has been introduced with the big Netty 4.1
update in PR #4397.

In Netty 3.x we always passed a "MessageEvent" through the channel
pipeline and got the remote address from that object. Since this object
doesn't exist anymore in Netty 4.x, we only pass the message payload's
"ByteBuf" through the pipeline and rely on the "Channel#getRemoteAddress"
method to always return the remote address object.

The problem is that this does indeed work for TCP based channels but it
doesn't work for UDP based channels. For UDP channels the
"#getRemoteAddress()" method always returns "null".

This is probably due to the connection-less nature of UDP.
For UDP transports Netty only creates a single channel. For TCP transports
there is one channel per TCP connection

To fix this we need to get our hands on the remote address when we
create the "RawMessage" object at the very end of the Netty pipeline.

Since we only pass the message payload "ByteBuf" through the Netty
pipeline, we could previously reuse several classes for TCP and UDP
transports because they were basically the same.

For UDP transports we now need to carry the remote address through the
pipeline by using a "AddressedEnvelope" (available in Netty) that takes
a payload and a sender/receiver object.

That means we have to create a few UDP specific - or rather
"AddressedEnvelope" specific - pipeline handlers because the shared ones
only know how to handle "ByteBuf" messages.

This PR moves some shared code out of the "NettyTransport" class up to
"AbstractTcpTransport" and "UdpTransport" so we can customize the
pipeline for the two different payload types. It also creates new
message aggregation handlers for the "AddressedEnvelope" objects.

In the future we can probably refactor this to share some more code, but
for 3.0 I tried to change as few as possible. The TCP pipeline is
basically unchanged apart from the "AbstractTcpTransport" change.

Fixes #5264
Fixes #5293

(cherry picked from commit 375e618)

This fixes an issue that has been introduced with the big Netty 4.1
update in PR #4397.

In Netty 3.x we always passed a "MessageEvent" through the channel
pipeline and got the remote address from that object. Since this object
doesn't exist anymore in Netty 4.x, we only pass the message payload's
"ByteBuf" through the pipeline and rely on the "Channel#getRemoteAddress"
method to always return the remote address object.

The problem is that this does indeed work for TCP based channels but it
doesn't work for UDP based channels. For UDP channels the
"#getRemoteAddress()" method always returns "null".

This is probably due to the connection-less nature of UDP.
For UDP transports Netty only creates a single channel. For TCP transports
there is one channel per TCP connection

To fix this we need to get our hands on the remote address when we
create the "RawMessage" object at the very end of the Netty pipeline.

Since we only pass the message payload "ByteBuf" through the Netty
pipeline, we could previously reuse several classes for TCP and UDP
transports because they were basically the same.

For UDP transports we now need to carry the remote address through the
pipeline by using a "AddressedEnvelope" (available in Netty) that takes
a payload and a sender/receiver object.

That means we have to create a few UDP specific - or rather
"AddressedEnvelope" specific - pipeline handlers because the shared ones
only know how to handle "ByteBuf" messages.

This PR moves some shared code out of the "NettyTransport" class up to
"AbstractTcpTransport" and "UdpTransport" so we can customize the
pipeline for the two different payload types. It also creates new
message aggregation handlers for the "AddressedEnvelope" objects.

In the future we can probably refactor this to share some more code, but
for 3.0 I tried to change as few as possible. The TCP pipeline is
basically unchanged apart from the "AbstractTcpTransport" change.

Fixes #5264
Fixes #5293

**Note:** This needs to be cherry-picked into 3.0

(cherry picked from commit 375e618)
@bernd bernd added this to the 3.0.0 milestone Jan 16, 2019
@bernd bernd requested a review from mpfz0r January 16, 2019 09:45
@kroepke kroepke merged commit 8868151 into 3.0 Jan 16, 2019
@kroepke kroepke deleted the issue-5293-3.0 branch January 16, 2019 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants