|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
I think you're misinterpreting how $sockbr is used
$sockbr returns the number of bytes you got from the very last /sockread call, which reads from the queue buffer.
If there is nothing in the queue, and nothing left to read then it naturally returns 0.
This is normal. Your results reflect this behaviour. You'll see that you loop 10 times and that the entire queue is read in the very first /sockread each time, leaving nothing left to read for the next 9 sockreads.
as far as .rcvd goes, you correctly point out that it updates after the sockread event only.. so as I mentioned, to keep score inside a specific sockread event you have to count with $sockbr.
I also gave you the code to do this. Where does the confusion lie?
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Jun 2004
Posts: 139
Vogon poet
|
|
Vogon poet
Joined: Jun 2004
Posts: 139 |
But why does it not keep reading more from the buffer when theres clearly more, it only carries on after the code has stopped and re-triggered. The help file says its quicker to keep reading rather then let it re-trigger, but all I see is it making problems...
If you look at my results its re-triggered many times after the 10 time loop...
289 17935 0
289 17935 0
289 17935 0
289 17935 0
289 17935 0
289 17935 0
289 17935 0
289 17935 0
289 17935 0
289 17935 0
re-triggered here
4385 17935 4096
4385 17935 0
4385 17935 0
4385 17935 0
4385 17935 0
4385 17935 0
4385 17935 0
4385 17935 0
4385 17935 0
4385 17935 0
re-triggered here
8481 17935 4096
8481 17935 0
8481 17935 0
8481 17935 0
8481 17935 0
8481 17935 0
8481 17935 0
8481 17935 0
8481 17935 0
8481 17935 0
re-triggered here
12577 17935 4096
12577 17935 0
12577 17935 0
12577 17935 0
12577 17935 0
12577 17935 0
12577 17935 0
12577 17935 0
12577 17935 0
12577 17935 0
re-triggered here
16673 17935 4096
16673 17935 0
16673 17935 0
16673 17935 0
16673 17935 0
16673 17935 0
16673 17935 0
16673 17935 0
16673 17935 0
16673 17935 0
re-triggered here
17935 17935 1262
17935 17935 0
17935 17935 0
17935 17935 0
17935 17935 0
17935 17935 0
17935 17935 0
17935 17935 0
17935 17935 0
17935 17935 0
Ninko
Last edited by Ninko; 27/03/08 01:03 AM.
|
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
The reason is that you're using /sockread &binvar which is a special case where looping isn't going to help because it will read the entire contents of the socket buffer into the binary variable at once. That means any subsequent looping won't read anything because the buffer won't be re-filled until the sockread event ends.
For any other usage of the /sockread command however looping will be useful because there will be no guarantee that the entire buffer will be read at once. For example if you change that line to something like /sockread 1000 &temp or /sockread -n &temp then you'll see that $sockbr does update correctly when there's more data to be read from the buffer.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
The socket buffer is 4096 bytes, you've read it all-- mIRC has nothing left to sockread until next ON SOCKREAD event.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Jun 2004
Posts: 139
Vogon poet
|
|
Vogon poet
Joined: Jun 2004
Posts: 139 |
So in this case I need to let it re-trigger its self? I don't mind either way, I was just going by the mIRC help file when it says its better to loop it rather then allow mIRC re-trigger.
Ninko
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
No-- you should loop-- this does not go against the help file. but you should realize that if you /sockread 4096 bytes (the default for a binvar) you will exhaust the buffer and there will never be anything left to read... so you can and *should* loop, but realize that if you're reading the default binvar size it will probably never actually iterate more than once-- you might want to keep the loop code though, just in case you change the read size down from 4096 in the future for some reason.
while ($true) {
sockread &bvar
if ($sockbr == 0) break
}
You'll see that only triggers once, but if you change the numbytes param on /sockread:
while ($true) {
sockread 1024 &bvar
if ($sockbr == 0) break
}
It would iterate ~4 times (for a full buffer).
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Jun 2004
Posts: 139
Vogon poet
|
|
Vogon poet
Joined: Jun 2004
Posts: 139 |
So if I lower the amount the binvar will read at a time, it will allow the buffer to update as the rest of the file comes in (the file size is 17965 bytes)? or am I still not understanding...
%1 = 0
:test
sockread 1024 &temp
bwrite etc etc &temp
%x = $sock(sockname).rcvd
echo -a %x %THEFILESTZE $sockbr
%1 = %1 + 1
if (%1 == 10) { halt }
else { goto test }
That would work then? Ninko
Last edited by Ninko; 27/03/08 03:32 AM.
|
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
right, but since the receive queue is maximally 4096 bytes, and mirc is able to read all 4096 bytes in a single /sockread &var, the point was not using a while loop in that case is the simplest and most efficient way forward about the %1 business in your code, in general you should loop until $sockbr (after a /sockread) or $sock().rq become 0. here's yet another template code in addition to the one mentioned earlier, this is just to read a line at a time but any other sockread variation can be used as well:
on *:sockread:name:{
var %var
while ($sock($sockname).rq) {
sockread -f %var
echo -a * %var
}
}
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
|
Joined: Jun 2004
Posts: 139
Vogon poet
|
|
Vogon poet
Joined: Jun 2004
Posts: 139 |
Ok ok, lets just forget all code for a min. The file I'm trying to download as I said is around 17965 bytes. And I think your saying the buffer can only hold 4096 bytes at a time? So of course it will take more then one buffer load to get the whole thing.
So what I'm asking here, does the code have to stop before the buffer will get the next load? I think we've already made the point about once you've read the whole buffer theres nothing more to read, but I was exspecting the buffer to update with the next load as the code went on.
Ninko
|
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
at the high level that is mircscript, yes, the code has to stop (the end of the sockread event must be reached) before mirc retriggers on *:sockread and gives you a new batch of data to handle
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
|
Joined: Jun 2004
Posts: 139
Vogon poet
|
|
Vogon poet
Joined: Jun 2004
Posts: 139 |
Right, now I understand, thats what I was getting at lol.
Ninko
|
|
|
|
|
Joined: Jan 2004
Posts: 162
Vogon poet
|
|
OP
Vogon poet
Joined: Jan 2004
Posts: 162 |
at the high level that is mircscript, yes, the code has to stop (the end of the sockread event must be reached) before mirc retriggers on *:sockread and gives you a new batch of data to handle
$sockerr
$sockerr is set to a value after each socket command/event and must be checked after each socket command and before processing an event to see if an error occurred.
that line should better be wiped from the help then, it's not true and in contradiction with the help example
on 1:sockread:testing:{
if ($sockerr > 0) return
:nextread
sockread %temp
if ($sockbr == 0) return
if (%temp == $null) %temp = -
echo 4 %temp
goto nextread
}
... where it also does not check after /sockread The $sockerr help line causes people to wrongly think $sockerr can change after each socket command, the word 'must' is even in bold. It's also contradictional with the /sockwrite help:
On error: if a /sockwrite fails, it sets $sock().wserr to the error value, and triggers the on sockwrite event with $sockerr set.
|
|
|
|
|
