HttpObject - Retaining old data?

#1 Just on a further note: I've been running the webserver at my datacenter for... 72 days and no probs. My game is, however, the only PHP scripts I run on it.

I went and updated to the latest ver of the webserver, downloaded and reinstalled the latest ver of PhP 5 (5.0.5 I think it is now) and reconfigured the PhP extensions in the webserver.

This problem is really infuriating. It seems to only happen if one of my data fields I'm passing is more than 8 characters long.... Which is why I suspected a problem with my Php interpreter but doing the above shouldve fixed it.

Argh =)

Thanks for any help. I surely cant be the only one using httpobject like this.

Mark

#2 Perhaps the problem is that you are using the same variable. Ex:

%Var1 = "GET /auth.php?id=16&crc=734945513&" and are reusing %Va1 without clearing it before hand. (Ex. Setting %Var1 to 0 or " ".)

Just something simple to try, I know it is small things like these that like to halt development.

#3 Thanks Anthony. No go. I think the problem is with my httpobject source code. I thought I had been using a clean build but this is a modified httpobject I had done a little tweaking on. I am going to try and compile a clean httpobject code and do more testing. I've had http object problems in the past and it was crappy source.

I really think thats the problem here. I've asked Harold for some assistance because my coding skills are terrible.

Mark

#4 I pretty much never use the HTTPObject at all. I use the TCPObject and construct the HTTP request myself.

$tcpserv = new TCPObject();   
$tcpserv.connect("www.server.com:80");   
echo("Command Send");

function TCPObject::onConnected(%this)
{   
   echo("sending");
   
   //Create HTML 1.0 POST line.  
   %htmlpost="GET /default.php HTTP/1.0\nHost: www.server.com:80\nUser-Agent: Torqu
e/1.0\nAccept: */*\n\n";
   
   //Send POST line to the webserver
   %this.send(%htmlpost SPC "\r\n");
   
   echo("sent");
}

function TCPObject::onConnectFailed(%this)
{
      echo("Connection Failed");
}


function TCPObject::onLine(%this, %line)
{
      echo(%line);
}

In your case you would need to add in a step to build the query string, and URL encode it.

// Replace SPC and + with HTML encoded alternative
%query=strreplace(%query," ","%20");
%query=strreplace(%query,"+","%2B");

To build the query you would check each variable you're adding, concatenate, and check if there were more then one so you know if you should use an &.

#5 Thanks for the great explanation Harold. I guess my question would be am I using the httpobject incorrectly? My concern with building my own http code using tcpobject is that I'll be increasing the processing overhead of every single query by almost 100%. (By the time the lines are parsed, sent etc.)

Do you still think it is worth it to use TCPObject? And if so my next question is:

In your example you show "onconnected" and "online" as their own functions but I need to access these bits of info from within several (as in 20-30) different functions. Would I simply use a return(%line)? I need to have lots of info handed back and worth between the webservers and the torque servers. If I can do this using return then fine but I'm a little concerned because sebsequent lines of code will require the responses from teh webservers PHP scripts.

I mean if I can just build the TCPO, the Query and then send it from inside an existing function, and check the responses with an ::online that would be great.

Thanks for your insight HArold. It's a great help.

Mark

#6 I'm a bit confused by your question. Even with the HTTPObject you will have to have an ::onLine function to process the return from the webserver.

HTTPObject is a specialized interface to TCPObject.

#7 Yes but I can reference the online by labelling the http object as in new httpobject(startup); etc.

Can I do the same thing with TCPO? I assume I can. I'll si tdown tonight and try and hash through some test TCPOs and see how I make out.

As far as the othe rquestions HArold you dont think using TCPOs is going to be higher overhead than HTTPOs?

Thanks for your help Harold I'm really looking forward to putting this bug to rest. It's a fairly major thorn in my side and will help me get moving on some Spawn code and inventory code that this is holding up heh.

Thanks a million
Mark

#8 I'm looking at some TCPO reference resources Harold and I'm wonderin gif I can eliminate the ::onconnect?

What I really need to do is package the query and send it in the same function. If I Cant do that how would I pass the var onto the ::onconnected? perhaps using %object.query?

I sure hope I'm making some sense here. So the difference with TCP Object is that I can package true HTML packets and do my own encoding of the ampersands using %26 as needed right? At least thats the way it appears to me tonight heh.

Thanks for all your help.

Mark

#9 Thank you Harold I've got this working and it does fix my variable length problem and stop the illegal characters from showing up in the logfile of my webserver.

Now more questions =)

Is there a way to send a TCPObject without waiting for the ::onconnect?

Basically I'm preping and packaging my send line in one function and I really dont want to have to make more global vars than I need to. So being able to do the .connect and the .send in the same function is really critical.

Is there any hope for me? My initial experimentation is not successful.

Thanks all

Mark

#10 It looks like you're past using HTTPObject now, but it doesn't handle multiple variables in a query string. You can modify it to fix that as shown here: Persistant Character Server

#11 I got HTTP object to handle many variables with a couple gentle nudges =) but it just wasnt stable. It would glitch out in different places and I cant afford to have an unstable datastream. It's worth it to do the switch to TPCOs but the onconnect thing is going to be a pain in the arse.

I get my datastream to work flawlessly using ::onConnects but it's at least doubling the processor overhead on the serverside and parsetime. Not a huge problem with 10-20 client but a very big problem with 50-100 clients all hammering away on the server simultaneously.

I can use globals for this but I'd really rather keep it clean and simple within a single function if possible. Then have the onLine responses handled in the second function.

Thanks for your tip on the other thread there. I think I've looked at that thread several times and infact I'm quite certain I tried the code there but it was buggy. Or perhaps I'm buggy =) both are very possible heh.

Mark

#12 I've been a bit busy getting ready for IGC and other things.. forgot to come back to this thread.

Ideally you would use an HTTP/1.1 Persistent connection (which shouldn't drop connection between requests)

Basically I'd setup a flow like this:

1. Data Requested
2. Do we have a server connection?
NO: Send Connect Request, then wait for ::onConnect, set global connected flag to send Query
YES: Send Query
3 Monitor ::onDisconnect event set global connected flag to false

I'm just really crunched for time so writing sample code isn't really even possible.. I think I have at least one example somewhere in the forums of doing an HTTP/1.1 POST request... it should be simliar to the GET the RFC rfc2616 should tell you what you need to know to construct an HTTP 1.1 query packet

#13 I think I've seen it Harold (your example code. Or someones anyways) I'll donkey around with it. Really appreciate your expertise I know what it's like to be crunched for time heh. Good luck with IGC. I Was really looking forward to coming but I simply cant spare the time right now. I Wanted to show off our private alpha client for Aakrana but it simply is not where I want it to be for public exposure.

Thanks a mill. I'll horse around with http 1.1 and see if I can make it behave.

Mark