|
Joined: Sep 2006
Posts: 59
Babel fish
|
OP
Babel fish
Joined: Sep 2006
Posts: 59 |
Because the queueing seemed to work better for me in 6.35 and below, I have tested my scripts on 4 different PCs and 1 laptop and had the same results with 6.35 so it isn't down to luck.
Try it yourself, and because I can't see what data was sent with the on sockwrite event so if I wrote multiple things to a socket and had a different action for each one I cannot check....
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Khaled himself said that previous versions behave the same way. He has access to the source code. He is the only one who can say with any certainty whether they behave the same way.
Can you name an example when you actually need to know what you've sent via a socket? It's usually the response you should be interested in. If you tell us what you're trying to do we might be able to suggest a better way of doing it.
|
|
|
|
Joined: Sep 2006
Posts: 59
Babel fish
|
OP
Babel fish
Joined: Sep 2006
Posts: 59 |
There is obviously something different in the 7.xx versions for it to only happen in these.
And just one example is sending some information to a server and then closing the socket so it can be used again but I may sometimes get a certain response from the server so I may want to write some more data and the value sent to the server will be dynamic so it will change at some point.
But I will still need to know what was sent in order to process the next action... and one would be closing the socket
Last edited by Rewtor; 17/02/11 09:05 PM.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Because the queueing seemed to work better for me This is generally not a reason to avoid best practices. As stated by Khaled and other users here, you CANNOT RELY on /sockwrite to immediately write data. You never could. The fact that it worked in 6.35 or prior versions means you were getting lucky, but this is not part of the spec. Implementation details that changed in subsequent versions made your luck disappear. To answer your initial question: Yes, you need to update your script to work properly. If you follow the SPEC then your script should work for many versions to come-- just like all the other socket scripts that have been working for me for years.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Then only perform a /sockclose in your ON SOCKWRITE event (after setting a flag or using /sockmark to let you know you can close the socket). For instance: on *:SOCKOPEN:mysock: {
var %i = 1
while (%i < 500) {
sockwrite -tn $sockname WRITING IMPORTANT DATA!!!
inc %i
}
sockmark $sockname done
}
on *:SOCKWRITE:mysock: {
if ($sock($sockname).sq == 0 && $sock($sockname).mark == done) {
sockclose $sockname
}
} This is how it should have been done from the start.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Dec 2002
Posts: 5,493
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,493 |
All versions of mIRC queue data with /sockwrite. It may be that older versions of mIRC attempted to send the data immediately however there would still have been no guarantee that it was sent. That is why it is important that you wait for an on SOCKWRITE to check whether your data was actually sent.
So, for example, you can issue multiple /sockwrite requests and when the on SOCKWRITE triggers you can check the $sock().sq to see if there is anything left in the send queue. If the send queue is zero, all the data has been sent and you can now close the socket.
If you do not do this in older versions of mIRC, you will find that your script may work most of the time but it will not be reliable since it will occasionally not send all of the data as expected.
|
|
|
|
Joined: Sep 2006
Posts: 59
Babel fish
|
OP
Babel fish
Joined: Sep 2006
Posts: 59 |
I'm currently checking $sockbr to see if everything has been read and checking $sock().sq to see if it has REACHED it's maximum value if so queue it in a timer to send again... BUT the above still does not let me see what data was sent in the sockwrite event which is what I would need to be able to do if I need to change my scripts for the new versions
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
It sounds to me like the real issue here is you aren't sure how to script it the proper way. Basically all you need to do is use a /sockmark instead of /sockclose after the final /sockwrite. This sockmark is the way you tell you are done writing to the socket and it can be closed when writing has finished. See the example that argv0 gave earlier because that's exactly what it does, and it doesn't add that many lines to your code.
|
|
|
|
Joined: Sep 2006
Posts: 59
Babel fish
|
OP
Babel fish
Joined: Sep 2006
Posts: 59 |
Oh ok I see what you're saying now something along the lines of...
on *:SOCKREAD:*:{
;read the data and whatever...
if ($1 == whatever) { sockwrite -tn $sockname blahdeblah | sockmark $sockname close }
elseif ($1 == blahdeblah) { sockwrite -tn $sockname whatever | sockmark $sockname dontclose }
}
on *:SOCKWRITE:*:{
if ($sock($sockname).mark == close) { sockclose $sockname }
elseif ($sock($sockname).mark == dontclose) { $nextaction }
}
That makes sense now. Sorry, was just a bit frustrated that it worked before but it doesn't anymore.
|
|
|
|
Joined: Dec 2002
Posts: 344
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Dec 2002
Posts: 344 |
Yes, something along those lines. However you should still check that $sock($sockname).sq == 0 before closing because ON SOCKWRITE can trigger in different conditions: The sockwrite event is triggered when mIRC has finished sending all of the data that you previously queued for sending or when the socket is ready for more writing.
|
|
|
|
Joined: Feb 2003
Posts: 307
Fjord artisan
|
Fjord artisan
Joined: Feb 2003
Posts: 307 |
Hello,
I believe i was the one that initially reported this issue. Some optimizations where done after my feedback and i can confirm that all together, mirc 7.17 is faster then mirc 6.35.
I am not sure when sending a few byte each time, but when sending files, i know what i am talking about.
You just have to make sure you use the perfect packet size (depends where you want to send it) when sending to buffer and keep the buffer always with something (meaning you aren't wasting the chance to send something in between).
I have done some research on this and i am able to go up to 4MB/s in data transfer, it is not much but it is a lot for mirc.
Regards
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
I have done some research on this and i am able to go up to 4MB/s in data transfer, it is not much but it is a lot for mirc. There have been many claims that mIRC is slow when it comes to transfers. Given your research is showing some pretty decent ( amazing if you mean MB == MBYTE and not mbit) results, it would be great if you could post a complete article / guide on the methods you're using to get this kind of speed. I think it would be helpful to other scripters who are having these speed complaints.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
For file transfers, mIRC's abilities have never been, and, imo, probably never will be the fastest method.
FTP is designed for file transfers and is, in my experience, a lot faster.
4MB/s (megabyte, not megabit) transfers are, in my experience, an excellent transfer rate for mIRC. Congratulations on obtaining this rate.
|
|
|
|
Joined: Feb 2003
Posts: 307
Fjord artisan
|
Fjord artisan
Joined: Feb 2003
Posts: 307 |
Hi again, Most of my research was obtained working on this script Web Server as a result most of what i have learned since i started playing with sockets was placed in it as well. What i have told you about trying to keep the socket buffer as full as possible and send the right packet size is the result of that research. Another tip is to keep the cpu usage as low as possible. I haven't been working much on it lately but my latest test during the 7.16 and 7.16 benchmark shown improvements on speed. My private version of this script uses something like congestion avoidance algorithm to find in real-time the best size to optimize speed transfer. You can also see for your self using that addon and converting line 1039 (if i am not mistaken) to a global var, then change the values until you get maximum performance. I can tell you it is by default optimized for internet transfers. You can try to find the optimal lan value, the one that allows transfers up to 4 MB/s (and yes, it is megabytes/second). Regards
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
As reguards to the whole buffer not sending imiately and you having to add a bunch of code and recode built in functions of mIRC to get the socket to do what you wanted, I did it by adding a single line to your code: on *:SOCKLISTEN:TestSocket:{
sockaccept test.s
echo -s socket accepted
sockwrite -tn test.s this is a test
}
on *:SOCKREAD:test*:{
if ($sockerr > 0) { echo -s error on socket | sockclose $sockname }
sockread -fn &Read.test | tokenize 32 $bvar(&Read.test,1,$bvar(&Read.test,0)).text
echo -s $sockname received: $1-
if ($1 == dotest) {
sockwrite -tn $sockname testing 1
sockwrite -tn $sockname testing 2
sockwrite -tn $sockname testing 3
}
}
on *:SOCKWRITE:test*:{
echo -s $sockname sent data
if (!$sock($sockname).sq) { echo -s $sockname Done sending data, closing socket! | sockclose $sockname }
}
on *:SOCKCLOSE:test*:{
echo -s $sockname socket closed
}
on *:SOCKOPEN:test*:{
echo -s $sockname socket opened
if ($sockname == test) { sockwrite -tn test dotest }
}
alias testsocket {
socklisten TestSocket 1010
sockopen test localhost 1010
}
alias sockwrite {
echo -s data sent to: $2 was: $3-
sockwrite $1-
} but if you wanted to be even more precise, you could check $sock().rq and $sock().secs before closing it....
Last edited by FroggieDaFrog; 19/02/11 05:24 AM.
|
|
|
|
Joined: Feb 2003
Posts: 307
Fjord artisan
|
Fjord artisan
Joined: Feb 2003
Posts: 307 |
Hello again Khaled,
Can we open this discussion? I have been noticing some heavy load on the clients side (browser) and I did some packet analyzing.
It seems that mirc, even if receiving packets of 4 to 8kB via sockwrite, it only sends much smaller packets to the clients, even if the buffer as like 8KB or more of data to send.
I have noticed sizes that vary from 700B to 1456B (never passing this value, I see a lot of reassembles on wireshark). Is this a max fixed limit or something on the TCP level?
Since most of the application can send 4k I was hoping mirc could as well or eventually up to 8k.
Best regards
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
tontito: If you're inspecting data at the packet level and are confused about seeing 1400byte packets, you should familiarize yourself with the MTU.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Feb 2003
Posts: 307
Fjord artisan
|
Fjord artisan
Joined: Feb 2003
Posts: 307 |
Thanks for reminding me of this.
The high cpu usage in the browser has to have some other explanation.
Regards
|
|
|
|
|