zeromq / netmq

A 100% native C# implementation of ZeroMQ for .NET
Other
2.94k stars 742 forks source link

Response Socket does not receive frame if client socket dies and new client socket reuses Identity #1014

Open stein212 opened 2 years ago

stein212 commented 2 years ago

Environment

NetMQ Version:    4.0.1.8
Operating System: macOS arm
.NET Version:     6.0.100

Expected behaviour

Response socket (server) receives frame and replies to Request socket (client)

Actual behaviour

Server does not receives the frame

Steps to reproduce the behaviour

var serverAddress = "tcp://localhost:5555";
var clientIdentity = "client 1";
using (var server = new ResponseSocket($"@{serverAddress}"))
{
    using (var client = new RequestSocket($">{serverAddress}"))
    {
        client.Options.Identity = Encoding.UTF8.GetBytes(clientIdentity);

        var request = "request 1";
        var reply = "reply 1";

        Log.Information($"Client sending {request}");
        client.SendFrame(request);
        Log.Information($"Server received {server.ReceiveFrameString()}");
        Log.Information($"Server sending {reply}");
        server.SendFrame(reply);
        Log.Information($"Client received {client.ReceiveFrameString()}");
    }

    using (var client = new RequestSocket($">{serverAddress}"))
    {
        client.Options.Identity = Encoding.UTF8.GetBytes(clientIdentity);

        var request = "request 2";
        var reply = "reply 2";

        Log.Information($"Client sending {request}");
        client.SendFrame(request);
        Log.Information($"Server received {server.ReceiveFrameString()}");
        Log.Information($"Server sending {reply}");
        server.SendFrame(reply);
        Log.Information($"Client received {client.ReceiveFrameString()}");
    }
}

If I do not set client.Options.Identity it works. I am under the impression that it is ok to set client.Options.Identity to the same value after the initial socket dies as the C# example for Lazy Pirate Pattern does requester.IdentityString = name; where name does not seem to be changed throughout the program.