Forums Scripts & Popups DCC socket

i'm writing a script which accepts a dcc file send with a socket for a custom dialog i can get the socket to connect but it causes errors to the sender... the sender needs an acknowlegement in NETWORK BYTE ORDER does anyone know how to do that conversion or if this script is incorrect
on 1:sockread:DCC:{
if ($sockerr > 0) { return }
sockread %dcc.data
if ($sockbr == 0) { return }
set %file.bytesent $calc(%file.bytesent + $sockbr)
echo -s %dcc.data
sockwrite -tn $sockname $sockbr
}

There are many threads relating to this topic.

See here for comprehensive code on how to both send and recieve.

Eamonn.

that's for a DCC chat i'm asking for a DCC send/recieve

Bah, so it is, my mistake.

so does that mean nobody knows how to do what i'm trying to ?

Give that a whirl, and see what happens

NETWORK BYTE ORDER is Most significant byte first, unlike x86 which stores least significant byte first.

In my dcc protocol doc it says "The recipient should acknowledge each packet by transmitting the total number of bytes received as an unsigned, 4 byte integer in network byte order", you were sending the last bytes read count, and you were sending it as text.
With luck the above well fix it.

this still did not work it's doing the same thing that the original code did... this is starting to make me angry

if you could explain to me what the calculations are doing in detail... are they putting the bytes sent into network byte order?

bah you have the same problems i was having with dcc sends using sockets (i asked for a script, no one had one ).

ok i dont know how much you know so ill try and break it down, I am leaving some things but there not to relevent here, this might be too simple if so im sorry.

A number is not normally stored as text which it is in mirc, normally its stored as 4 bytes of data, if you had the value 45, it would be stored under x86 cpu as 45,0,0,0 if the value was 255 its 255,0,0,0 since 255 is the highest value a byte can hold if we want to store 256 we end up with this 0,1,0,0 its like an abucus the second number represents x256, 3rd x65536 (becuase this is 256x256) and 4th x16777216 (becuase this is 256x256x256), so if we wanted to store 1000000 its 64,66,15,0 (64 + 66x256 + 15x65536 + 0x16777216).
OK hopefully that sorts out how numbers are stored under x86, well NETWORK BYTE ORDER is simply the other way around the 1000000 would be stored 0,15,66,64 (0x16777216 + 15x65536 + 66x256 + 64)

now what i did in my calculation....

"%file.bytesent / 16777216" this gets the value for the 1st of the 4 numbers but it might have a decimal place to i shave it off using $int

"%file.bytesent / 65536" this gets the value for the 2nd of the 4 numbers how ever it has the 1st value x 256 also in it so i have to get ride of that, i do that by using the "% 256" which might be better known as MOD ( divide by 256 and take the remainder as your answer ) but it might have a decimal place to i shave it off using $int

"%file.bytesent / 256" this gets the value of the 3rd of the 4 numbers again however it has the 1st number x256x256 and the 2nd number x 256 also in it, again got to get ride of them so again just use "% 256" and all the others come off. but it might have a decimal place to i shave it off using $int

"%file.bytesent % 256" this gets the value of the 4th number since its the least amount we just remove all the others from it by using "% 256"

I include this following set of calculations to show it not using the % method that does confuse some people.

num1 = int(%file.bytesent / 16777216)
num2 = int((%file.bytesent - (num1 * 16777216)) / 65536)
num3 = int((%file.bytesent - (num1 * 16777216) - (num2 * 65536)) / 256)
num4 = %file.bytesent - (num1 * 16777216) - (num2 * 65536) - (num3 * 256)

As u see the calcualtion is more intensive but easier to under stand

Hope this helped. If you dont have anymore sucsess tell me ill try again, see if i can get anywhere, i hate working of specs, because u often find there is some small point missed out

ok now i've tried every single way to convert network byte order into a binary variable and sending that as an ack. i called my best friend and had him look up the conversion for htol in C++ and sending that number also NONE of these things work NOTHING... i'm almost ready to give up because i don't know if mirc is capable of doing it

dave i got it your $int's were out of order... i appreaciate this sooooo very much thanks thanks thanks!!!

Post the code to make the value, id like to see what i did wrong becuase i cant see it, but it must faulty somewhere in there.

excuse me they werren't out of order but you have to set them to a variable before bset'ing the value
on 1:sockread:DCC:{
if ($sockerr > 0) { return }
sockread %dcc.data
if ($sockbr == 0) { return }
set %file.bytesent $calc(%file.bytesent + $sockbr)
echo -s %dcc.data / the data
bunset &fbs.rnbo
set %nbo.data $int($calc(%file.bytesent / 16777216)) $int($calc(%file.bytesent / 65536 % 256)) $int($calc(%file.bytesent / 256 % 256)) $calc(%file.bytesent % 256)
bset &fbs.rnbo 1 %nbo.data
sockwrite -b $sockname 4 &fbs.rnbo
if (%file.bytesent == %file.total) { sockclose $sockname | echo -a send complete of file }

the code works perfectly for smaller files but when it comes to bigger files it seems not to work the last 1000-2000 bytes don't come through... can't find any reason for this but its doing it...