Author Topic: RTB Development  (Read 328095 times)

It's not about sending data.

It's about receiving data.

Not my point. In any case, have the parser notice broken XML and send a report to Ephialtes instead of starting a crash loop. That make sense?

I've had an enormous amount of connections (about 12000 by 5 servers) to the RTB server that didn't close.

Code: [Select]
//--- OBJECT WRITE BEGIN ---
new ScriptGroup() {
   class = "RTB_TCPFactory";
      headerConnection = "close";
      headers = "3";
      header0 = "Host";
      header2 = "Connection";
      headerUser-Agent = "RTB/4.0";
      port = "80";
      host = "api.returntoblockland.com";
      header1 = "User-Agent";
      resource = "/apiRouter.php?d=APISA";
      headerHost = "api.returntoblockland.com";

   new TCPObject() {
         factory = "4226";
         receiving = "0";
         dead = "0";
         connected = "0";
         request = "POST /apiRouter.php?d=APISA HTTP/1.1\r\nContent-Length: 93\r\nContent-Type: "
            @"application/x-www-form-urlencoded\r\nHost: api.returntoblockland.com\r\nUser-Agent: "
            @"RTB/4.0\r\nConnection: close\r\n\r\nn=LegoPepper&b=3763&c=POST&arg1=31300&"
            @"arg2=0&arg3=&arg4=&arg5=&arg6=&arg7=&arg8=&arg9=&arg10=";
         module = "RTB_Server_Authentication";
         lineCallback = "onPostReply";
   };
   new TCPObject() {
         factory = "4226";
         receiving = "0";
         dead = "0";
         connected = "0";
         request = "POST /apiRouter.php?d=APISA HTTP/1.1\r\nContent-Length: 93\r\nContent-Type: "
            @"application/x-www-form-urlencoded\r\nHost: api.returntoblockland.com\r\nUser-Agent: "
            @"RTB/4.0\r\nConnection: close\r\n\r\nn=LegoPepper&b=3763&c=POST&arg1=31300&"
            @"arg2=0&arg3=&arg4=&arg5=&arg6=&arg7=&arg8=&arg9=&arg10=";
         module = "RTB_Server_Authentication";
         lineCallback = "onPostReply";
   };
   new TCPObject() {
         factory = "4226";
         receiving = "0";
         dead = "0";
         connected = "0";
         request = "POST /apiRouter.php?d=APISA HTTP/1.1\r\nContent-Length: 127\r\nContent-Type: "
            @"application/x-www-form-urlencoded\r\nHost: api.returntoblockland.com\r\nUser-Agent: "
            @"RTB/4.0\r\nConnection: close\r\n\r\nn=LegoPepper&b=3763&c=POST&arg1=31300&"
            @"arg2=1&arg3=LegoPepper%3B75.142.240.41%3B0%3B2&arg4=&arg5=&arg6=&arg7=&arg8=&arg9=&arg10=";
         module = "RTB_Server_Authentication";
         lineCallback = "onPostReply";
   };

   [...]

}

Code: [Select]
Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    69.64.33.32:49159      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49160      173.230.133.148:80     CLOSE_WAIT      11376
  TCP    69.64.33.32:49162      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:49164      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49165      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49167      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49168      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:49169      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49170      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:49171      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49172      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49173      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:49174      173.230.133.148:80     CLOSE_WAIT      5364

[...]

  TCP    69.64.33.32:65515      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65516      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65517      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65518      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65519      173.230.133.148:80     CLOSE_WAIT      11376
  TCP    69.64.33.32:65520      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65521      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65522      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65523      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65524      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65525      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65526      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65527      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65528      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65529      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65530      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65531      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65532      173.230.133.148:80     CLOSE_WAIT      2992
  TCP    69.64.33.32:65533      173.230.133.148:80     CLOSE_WAIT      5364
  TCP    69.64.33.32:65535      173.230.133.148:80     CLOSE_WAIT      2992

However, this looks more like an engine bug.

Actually I think that's a bug I've fixed in RTB 4.01 - I'll be releasing that shortly. If you want to fix it in the meantime throw this at the bottom of dedicated.cs:

Code: [Select]
//*********************************************************
//* Activate Packages
//*********************************************************
activatePackage(RTB_Support_Networking);

Seems like an engine bug that is exacerbated by whatever I did - either way it's a bit weird, but this fixes it ^
« Last Edit: November 04, 2011, 03:26:23 PM by Ephialtes »

And how exactly did it happen?

Found out why it happens. (the infinite loop problem, not the connections problem)
Code: [Select]
>> [11/04/11 17:31:44] <message from="5030" to="General Discussion"><body>Typos, Y u happen?</body></message>
>> Disconnected
>> [11/04/11 17:31:47] <notice from="General Discussion" typ
Looks like it disconnected while it was receiving data, then shows this:

Code: [Select]
getSubStr(...): error, starting position and desired length must be >= 0: ("<notice from="General Discussion" typ",1, -2)
BackTrace: ->RTBCC_Socket::onLine->XMLParser::bufferData
Over and over.

Explains why it happens while starting a server from a copy of Blockland from a flash drive. It probably took longer than normal, causing a disconnection.

And how exactly did it happen?

Forgot to activate a package.

Found out why it happens. (the infinite loop problem, not the connections problem)
Code: [Select]
>> [11/04/11 17:31:44] <message from="5030" to="General Discussion"><body>Typos, Y u happen?</body></message>
>> Disconnected
>> [11/04/11 17:31:47] <notice from="General Discussion" typ
Looks like it disconnected while it was receiving data, then shows this:

Code: [Select]
getSubStr(...): error, starting position and desired length must be >= 0: ("<notice from="General Discussion" typ",1, -2)
BackTrace: ->RTBCC_Socket::onLine->XMLParser::bufferData
Over and over.

Explains why it happens while starting a server from a copy of Blockland from a flash drive. It probably took longer than normal, causing a disconnection.

Perfect thanks. I guess an easy fix in this instance would be to make sure the last character on the line is a > otherwise the line can be discarded.

I've improved the timing out code now so it tries to ping you three times before throwing you off the irc so these two things combined should satisfy most cases. I'll put these both into the next update.


wut

Well, Internet Chat Relay might still describe how it works...

Well, Internet Chat Relay might still describe how it works...
Oh i see, thanks.

The problems with the XML parser is getting annoying, third time I have crashed due to it now =/.


EDIT: It's consistent now. Every time I try to start a server I get the XML parser's infinite loop.
« Last Edit: November 06, 2011, 12:29:01 PM by pecon98 »

The problems with the XML parser is getting annoying, third time I have crashed due to it now =/.


EDIT: It's consistent now. Every time I try to start a server I get the XML parser's infinite loop.

If it happens every time, can you type trace(1); before you start the server then upload the console.log?

Will do, just one second.

EDIT: Predictably it was too big for an attachment.
http://pecon.us/storage/console.log
« Last Edit: November 06, 2011, 12:37:27 PM by pecon98 »

Will do, just one second.

EDIT: Predictably it was too big for an attachment.
http://pecon.us/storage/console.log

There's no infinite loop in this log - the last one had it, this one looks fine.

Guess I stopped too soon, it was hard to tell since tracing the console causes plenty of other spam. Trying again.

EDIT:
Updated the file. http://pecon.us/storage/console.log