|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
I'd like to see blocking sockets in the next version of mIRC. Then we can finally /return data retrieved from a webserver. They could be implemented in a similar way to the php sockets or mIRC file handling commands: alias test {
sopen 100 google google.com 80
; 100 is a timeout parameter in seconds.
; mIRC waits until the socket has opened, there's an error or it reaches the timeout parameter.
if ($sopen(google)) {
swrite -n google GET / HTTP/1.1
; mIRC waits until the data has been sent.
swrite -n google Host: www.google.com
; mIRC waits until the data has been sent.
swrite -n google Accept: */*
; mIRC waits until the data has been sent.
swrite -n google
; mIRC waits until the data has been sent.
while (!$sopen(google).feof) echo -s $sread(google)
; Read and echo all data to the status window.
}
elseif ($sopen(google).timeout) {
echo -s google socket timed out.
sclose google
}
else echo -s There was an error: $wserr $wsmsg
}
|
|
|
|
Joined: Apr 2004
Posts: 218
Fjord artisan
|
Fjord artisan
Joined: Apr 2004
Posts: 218 |
I am going to concur with you on this. This will make (IMO) socket handling more easier, without having to use "on EVENT"'s.
Live to Dream & Dream for Life
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
socket ARE event type objects, so what else would you expect besides that they well be event driven?
All the above code would be is a "exit script" with special hidden ON EVENT for the remaineder of the script. Why write this in when the devices to access sockets have already been created.
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
This seems like a reasonable idea to me. The biggest advantage that I see is that your script wouldn't have to store identifiers into variables so that they can be accessed in the on SOCK* events. For example, this:
on *:TEXT:!points:#:{
set %nick $nick
set %chan $chan
sockopen points www.points.com 80
}
on *:SOCKOPEN:points:{
sockwrite -n $sockname points.php?n=%nick&c=%chan http 1.1
;etc
}
on *:SOCKREAD:points:{
sockread %s
if (%s == something) { msg %chan %nick has $4 points }
unset %chan
unset %nick
}
(not real code) could become this:
on *:TEXT:!points:#:{
sopen 100 points www.points.com 80
if (!$sopen(points)) return
swrite -n points points.php?n=$nick&c=$chan http 1.1
if ($sfail(points)) return
while (!$sread(points).feof) {
if ($sread(points) == something) msg $chan $nick has $4 points
}
sclose points
}
It would be meant for the simplest sockets only. More complex ones would still be able to use the regular non-blocking sockets and events. -genius_at_work
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
Except in a single-threaded environment like mIRC scripting, anything lasting more than 1-2 seconds is going to cause issues. In hixxy's example he uses a timeout of 100 seconds, can you imagine if there was no response on the socket and mIRC was actually frozen for that long? Of course it's only an example figure he's using but with the short timeouts necessary to prevent this becoming a major issue it would severely impact the usefulness of these identifiers due a high number of timeouts.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
I was thinking that ctrl+break or maybe a whole new key combination could close a connecting socket.
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Actually, full support for both is included in the windows API.
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
I think the blocking sockets would work similar to how $input works. Maybe they couldn't be called from within an event (voids my previous example :P ), but they could be called manually as an alias, or from a timer.
-genius_at_work
|
|
|
|
Joined: Oct 2003
Posts: 88
Babel fish
|
Babel fish
Joined: Oct 2003
Posts: 88 |
This would be a great feature in my oppinion, although I dont agree with the names of your commands so much.
|
|
|
|
|
|