I have now spent close to a month on trying to get a TCP Listener working in 4.19.
I have tried every piece of sample code on the wiki, most of which was provided by Rama, but most of which have since been replaced by the FTCPListener class. In fact, I even tried his code without using the FTCPListener class especially given the doubt that exists if this class works correctly. The amount of churn about this topic over the last year or so is amazing. At some point people were discouraged from using FTCPListener and I am not sure that I have seen any post that gives the green flag to use it again.
I did a search on Unreal Engine and TCP Listener for the last two years and tried every piece of code, and every variance that was provided. In one posting a company offered up code where they modified Rama’s code. (Thread link: https://forums.unrealengine.com/deve…-python-script )
That seemed to provide a good alternative using the FTCPListener class but then as you read down the thread you start to get the same symptom show up that I experienced. People that try the code and that realize, like I did, that the receive does not work for some reason. The waiting for pending connection signals an incoming connection. The accept works and then the receive delivers nothing and also no error message. When I do an initial send on connection (like some TCP Listeners do), the client sees that but the message from the client is not received. I tried every possible combination of the listening backlog, blocking, non-blocking, reusable, etc to no avail. In desperation I tried to make Unreal the client and run the server somewhere else. Very similar unstable results. Sometimes message replies are received into UE - other times they are simply lost.
I wrote test clients and servers in C#, I used network testing tools that emulate TCP listeners and clients, I have run clients on repeat that connects every second and blasted UE to see if it is a timing issue (which I still think it is), but could not get predictable results. Once or twice when I would run UE in debug mode from Visual Studio and create a break point in the C++ code, the receive would magically work and the moment I run UE by itself and don’t have insight into the code - the receive fails. Then I debug in C++ again but suddenly the receive even fails in debug.
Whenever I test the non-UE listeners and clients I wrote and/or the test tools against each other, everything works perfectly. This is, after all not rocket science and I have created many listeners on different platforms in different languages from Assembler, C, C++, Java, and now C#. This is easy - the kind of stuff you give a junior programmer to do.
But the mushy mass of library upon library in the TCP category - in order to provide a universal socket library for all - seems to have created a socket library for nobody. One Epic support person/or developer referred to code rot inside the TCP library area - presumably referring to the FTCPListener library. Another symptom of that - the amount of socket libraries for sale on Epic Marketplace. Which honestly might be my last resort.
But could Epic perhaps intervene here and present us with the simplest of sample code that will run an echo TCP Listener on UE on Windows (which I assume is a fairly large part of the user community). Perhaps you could even blueprint enable it and then it is something we can run as each release comes out to ensure that the socket library is still working. I am willing to help in whichever way you need me to get this into existence.
I don’t mean to be disparaging but come on Epic, those C++ Reference libraries you generate from code is not helping us. Awesome individuals like Rama makes it better but sometimes it makes it worse because his code gets stale and then it suddenly doesn’t work on the latest release of Unreal and confuse the people looking at it. I almost hesitate to ask because at this stage getting a reliable TCP listener will be like a miracle. But it is logical to want to make a listener not run on the game thread - hence the FRunnable heritage of FTCPListener I presume. But this would be the right way to provide the code.
I do have appreciation for the challenge of getting all this functionality to work on so many platforms. I have been in a similar situation with C++ products that was deployed on many different hardware platforms so I understand the challenge. But we need you help here…
