Author Topic: TCPObject Saving binary data of unknown length  (Read 6142 times)

Each argument in tcpObject::send is sent as a different line. 0x0A is the hexadecimal for a new line character.
so basically... you're sending
%line @ "\r" @ 0x0A aka \n?

let me go wrap this in

so basically... you're sending
%line @ "\r" @ 0x0A aka \n?

let me go wrap this in
I'm not sending an \r. New lines are declared in text files as \n not \r\n so there's no need for an \r when you send it to be directly encoded. I guess I'm kind of sending %line @ "\n", except they'll be on two different onBinChunk calls, but since they'll be right next to eachother in the buffer it'd be similar. Also, I should note for the very last send you cannot have a \n character or it will corrupt the file. I recommend doing like this:

while(1)
{
%tcp.send(%f.readLine());
if(%f.isEOF())
break;
%tcp.send(0x0A);
}


but then you don't get to use your cool new multiple arguments in one call idea.

i was too lazy to open a text file and copy a tab, or spam space
« Last Edit: August 10, 2012, 03:21:54 AM by TripNick »

i caught that if(%tcp!!!!!

testing.


yeah no that didn't work so well.

-rw-rw-r-- 1 lugnut lugnut         0 Aug  9 15:54 img (1).png
-rw-rw-r-- 1 lugnut lugnut         0 Aug  9 15:54 img (2).png
-rw-rw-r-- 1 lugnut lugnut         0 Aug  9 16:14 img (3).png
-rw-rw-r-- 1 lugnut lugnut         0 Aug  9 16:18 img (4).png
-rw-rw-r-- 1 lugnut lugnut       796 Aug 10 00:39 img (5).png

on the bright side, that's the first time it ever transmitted and actually gave me any data.


... perhaps it's closing the connection early.
« Last Edit: August 10, 2012, 03:34:46 AM by Lugnut »

i caught that if(%tcp!!!!!

testing.
yeah i wrote the code on the spot lol, would have crashed my blockland ono



yeah no that didn't work so well.
I think Kalphiter is right and it's impossible, what I failed to take into account was that Torque is a parsed scripting language. When you call %f.readLine() it returns the result as a string, despite it's reading mechanism.
« Last Edit: August 10, 2012, 03:36:56 AM by TripNick »

nope, disabling my timeouts didn't help.

yep. that's loving gay >:(

At least you can run Blockland and do tests. I would have said more stuff but I usually run tests before I speak about things that I could be wrong about.

oh you think i'm running blockland? ahahaha no.

i'm using kalphiters dedicated running v20.

i forget the content of your posts, i've seen a bunch of errors. you can't play v21?

i forget the content of your posts, i've seen a bunch of errors. you can't play v21?
I can't play v21. Crash on open bug. Does Kalphiter's service not work with v21? Even my linux server works with v21. Anyway; I don't post faulty code and I don't post instructions I don't know for a fact work. If I have any doubt I test it.

Kalphiters service works. Im just holding off on updating it.
Bl runs... as good as ever under wine for me, so yeaaaah...

Kalphiters service works. Im just holding off on updating it.
Bl runs... as good as ever under wine for me, so yeaaaah...
You run linux? New found respect for you.

I have no experience with it but the reason I said what I did is because fileObjects may read as binary, in which case you should be able to send null characters over a tcpconnection as long as you don't turn it into a string, as Lugnut erroneously did.
No, this is not how it works

Once you enter it as an argument for a function, the data becomes handled at the Torquescript level.

You run linux? New found respect for you.
I'll admit it's primarily because windows blew up, and I couldn't restore it, but there is no way i'm putting windows on this machine even if I had the opportunity. I like linux too much.


will definitely keep windows on another computer for compatibility.

Due to how Badspot seems to run the images through a proxy(Look at HTTP header Vary) it is quite odd that they wont return correct information for respective file. Therefor, I threw together a script on my host and cleaned up the script that was provided in this thread.

It is like a relay where it downloads the file to the server and outputs its own version with correct used headers.
http://redirect.aposoc.net/image.blockland.us/detail.php?q=98-218-192-31_28000
(If you got Firefox you can press Ctrl+Shift+K to get up Web Console and check the headers there)

The script is followed below:
Code: [Select]
$imgDownloader = new tcpObject(imgDownloader);

// Connecting
function imgDownloader::onConnected(%this)
{
// Prepare file
%file = "/image.blockland.us/detail.php?q=" @ strReplace(strReplace(%this.ip,".","-"),":","_");
%this.contentLength = 0;
%this.send("GET " @ %file @  " HTTP/1.0\r\nHost:redirect.aposoc.net\r\nAccept-Encoding: identity\r\nTE: identity\r\n\r\n");
}

// Getting text
function imgDownloader::onLine(%this, %line)
{
%var = strlwr(firstWord(%line));
%value = restWords(%line);
// Check size
if (%var $= "content-length:")
%this.contentLength = %value << 0;
// Start transfer of binary file
if (%line $= "")
%this.setBinarySize(%this.contentLength);
}

// Getting binary file
function imgDownloader::onBinChunk(%this, %size)
{
if (%this.contentLength !$= 0 && %size >= %this.contentLength)
{
%this.finish();
%this.disconnect();
}
}

// Finishing up
function imgDownloader::finish(%this)
{
%this.saveBufferToFile("config/preview.png");
}

// Prepare and connect
function imgDownloader::downloadImg(%this, %ip)
{
%this.disconnect();
%this.setBinary(0);
%this.ip = %ip;
%this.connect("redirect.aposoc.net:80");
}
Try connect it with:
Code: [Select]
$imgdownloader.downloadImg("98.218.192.31:28000");Should work most the time.

If code is abused, I sure will take down the link. I can provide with PHP code if anyone is interested.

No, this is not how it works

Once you enter it as an argument for a function, the data becomes handled at the Torquescript level.
I think Kalphiter is right and it's impossible, what I failed to take into account was that Torque is a parsed scripting language. When you call %f.readLine() it returns the result as a string, despite it's reading mechanism.
I've already come to this conclusion. Thanks for the tip, though!!