Announcement

Collapse
No announcement yet.

Bug: TCPLink does not function properly, also spams log

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Bug: TCPLink does not function properly, also spams log

    First -- when not actually connected to something, the TCPLink spams the log every tick with various information about what it's doing. Vaguely helpful, mostly annoying. Also, the disk copy of the log file stops being recorded at this point. This is very unhelpful.

    Second -- The TCPLink cannot handle datarates of any reasonable speed. If I pump data to it from an internet server as fast as I can, it stops after about 100 characters or so, and just aborts that receive, and goes onto the next transmission. If I put a 50ms pause every 100 char, then I can receive all the data that is sent.

    #2
    1) that only happened to me in some cases, for example trying to connect to an invalid port (i.e. 0 >= port > 65535) and in a case where the network connection was screwed up. In the latter case I never found out what the cause was.

    2) I never had any problems with that, or at least not in UT3 and earlier UDK builds. How are you reading the data?

    Comment


      #3
      re the log spam, any connection that i try to make, from the point i run resolve() to the point it is actually connected, or if there is a connection error, i get it every tick until it actually gets connected, or i close the game.

      I've run it in both MODE_Text and MODE_Line.

      test php code snippet:
      Code:
      for($i = 0; $i < 10; $i++) {
          socket_write($socket, "This is a test $i\r\n".chr(0))
      }
      test unrealscript code snippet:
      Code:
      event ReceivedLine( string Text ) {
          `log("Server says:"@Text);
      }
      The unrealscript consistently only logs the first two "This is a test" lines, and loses the rest. If I put a 50ms delay (usleep(500000)) in the php loop, then i receive all 10 lines at the unrealscript end.

      Comment


        #4
        transmitting a 512 byte string via tcplink requires that the server sending the data to the unrealscript client wait over 1 full second before sending any more data

        Comment


          #5
          That's really odd, I haven't come around to test this stuff yet.

          Comment


            #6
            about a 700ms delay works for me on the same network, i had to bump it to 1100ms before my companion halfway around the world was able to receive the same data. i may have to add some kind of handshake response type thing after each piece of data is received, although i'd really expect that there would be a somewhat larger buffer on the tcplink..

            Comment


              #7
              I know this means taking the hardroute, but why not use DLLBind to create a local TCP listener? With a few arrays and functions, you easily read stuff into the game from the Tick event.

              eg:
              Code:
              __declspec(dllexport) int GetMessageSize()
              __declspec(dllexport) wchar_t* GetMessage(int index)
              __declspec(dllexport) void ClearMessages()
              It saves all recieved messages into a buffer array untill you request GetMessageSize(), this will copy the current buffer array to a temp buffer array which you return the size of, the other buffer array will be cleared for new messages coming in.

              GetMessage() get the message of the temp buffer array and ClearMessages() clears the temp buffer array so you can use GetMessageSize() again.

              Here how you would use it in UnrealScript:
              Code:
              event Tick(float DeltaTime)
              {
              	local int i, messagesize;
              	
              	messagesize = GetMessageSize();
              	
              	if(messagesize > 0)
              	{
              		for(i = 0; i < messagesize; i++)
              			`Log(GetMessage(i));
              			
              		ClearMessages();
              	}
              }

              Comment


                #8
                well, that could be done, but first, the only thing i have to compile windows c code on is GCC, which I can't seem to find any information whatsoever on building a dll of the proper style .. and it ignores that the known "performance issue" appears to be more of a "can't be used for anything useful"..

                Comment


                  #9
                  You could download the free Visual C++ Studio of Microsoft, it works great for DLLBind. OR if you're student, try to get into the MSDNAA-program to get a free copy of the full Visual Studio.

                  And you can mix C++ and C together to a certain degree, UnrealScript just expects you to give it primitives, although I'm sure it's also possible to eventually pass around Objects.

                  Comment


                    #10
                    i thought the free visual studio was sans compilers? and last time i tried to install a VS product, it utterly destroyed my system, so i'm a bit nervous about that

                    Comment


                      #11
                      VisualStudio has done some serious jumps since the times of VS6. The 2005 and 2008 are usable without any danger to the system and the the free version contains anything you need for c++ development. The only restriction is that you can't use external plugins, but in some other thread someone posted a way to install nFringe with the free version.

                      Hope that helps

                      Comment


                        #12
                        Still, the function should not be utterly broken, as it appears to be. (I've now tested this in all three UDK releases, and I'm unable to receive anything more than 2 lines or 140 characters, without putting at least a 300ms delay between them)

                        I've also tested polling and event modes, in both line and bulk, and all of them are just dropping any data received after that point.

                        Comment


                          #13
                          Have you tried the TcpLinkClient example from the UDN? Because that worked perfectly when I wrote it.

                          Comment


                            #14
                            Found the problem -- server sends null terminated strings, which causes the tcplink to drop input regularly.

                            Comment

                            Working...
                            X