ObjectDeliverer Version 1.2.1 Released

This time, I fixed the following bug pointed out by a user.

  • Editor crashes if a port already in use is specified for UDPReceiver
InnerSocket = FUdpSocketBuilder(TEXT("ObjectDeliverer UdpSocket"))
        .WithReceiveBufferSize(1024 * 1024)
        .BoundToPort(BoundPort)
        .Build();


Receiver = new FUdpSocketReceiver(InnerSocket, FTimespan::FromMilliseconds(10), TEXT("UProtocolUdpSocketReceiver"));
Receiver->OnDataReceived().BindUObject(this, &UProtocolUdpSocketReceiver::UdpReceivedCallback);
Receiver->Start();

if (InnerSocket)
{
    DispatchConnected(this);
}

The above is the source code before the fix.

If a port number already in use was specified for BoundPort, InnerSocket would contain nullptr, causing a crash when FUdpSocketReceiver was subsequently generated.

This time, I simply fixed it as follows:

InnerSocket = FUdpSocketBuilder(TEXT("ObjectDeliverer UdpSocket"))
        .WithReceiveBufferSize(1024 * 1024)
        .BoundToPort(BoundPort)
        .Build();

if (InnerSocket) // Check if socket creation was successful
{
        Receiver = new FUdpSocketReceiver(InnerSocket, FTimespan::FromMilliseconds(10), TEXT("UProtocolUdpSocketReceiver"));
        Receiver->OnDataReceived().BindUObject(this, &UProtocolUdpSocketReceiver::UdpReceivedCallback);
        Receiver->Start();
    DispatchConnected(this);
}

Now, even if initialization with FUdpSocketBuilder fails, it will no longer crash.

After finding this bug, I wondered if the TCP/IP Server, which has a similar mechanism, was okay, but that one already had a guard in place and was fine.

I’m embarrassed to have made such a simple mistake.