John Craig wrote:
Alex Tweedly wrote:
I don't know of a way to do this directly - certainly nothing I can
see in the docs, and haven't seen it done.
There is a pretty nasty (but generally effective) way to do it .....
Thanks, Alex. The reason I asked was that I have hooked up an Aviosys
IP POWER 9200 box to a network. It has digi inputs and outputs for
controlling mains appliances. You can set the port that it accepts
data on, but it always replies on another port, so the handler for
UDP replies never gets called. I thought if I could determine the
local port used I could then listen for the reply data. I'm just
using the default port that it sends the replies to and it's working
fine.
No, you really don't need to do that John (and indeed, you can't do that
:-).
The docs are pretty unclear (OK, they're *absolutely* hopeless) about
this. The docs say
Establishes a TCP communications socket between your system and
another system.
open [datagram] socket [to] host[:port[|ID]] [with message
callbackMessage]
open secure socket [to] host[:port[|ID]] [with message
callbackMessage] [with|without verification] [using certificate
certificate and key key]
<snip>
Description
Use the open socket command to open a connection to another system on
the Internet (or another IP network) to get and send data.
Parameters:
The host is the IP address or domain name of the host you want to
connect to.
The port is the port number you want to connect to. If you don't
specify a port, port 80 is used. (On most systems, port 80 is used for
HTTP connections.)
The ID is an optional connection name for the socket, and can be any
string. Specify an ID if you want to create more than one socket to
the same host and port number, so that you can distinguish between them.
The callbackMessage is the name of a message to be sent **when the
connection is made**.
Comments:
When a connection is made, the open socket command creates a new
socket that can be used to communicate with the other system. The
handler continues executing while the connection is being established.
If you use the write to socket command while the connection is
opening, the data is buffered and is sent to the host as soon as the
connection is made.
Use the open datagram socket form if you want to send a connectionless
UDP datagram instead of opening a socket.
If you specify a callbackMessage, the message is sent to the object
whose script contains the open socket command, *as soon as the
connection is made*. The first parameter pf this message is the host
and port number of the socket. Use a callbackMessage to trigger
actions (such as reading from the socket) that must wait until the
connection has been established. (To pause the handler that contains
the open socket command until the callbackMessage is received, use the
wait for messages form of the wait command.)
This describes the "callbackMessage" parameter correctly for TCP sockets
(i.e. open socket)., but is totally misleading for UDP sockets (i.e.
open datagram socket).
For UDP sockets, the callbackMessage parameter is the name of the
handler which will be called when (if) any reply packets are received.
This kind of makes sense (there is no "connection" as such, so no need
for a callback when a connection is opened, and there is a need to be
told when reply packets arrive - and this is a better way than telling
you which local port was assigned, since you;d need to *then* accept
packets on it, which would be a race condition between the accept
command and the packets getting to/from the other machine).
So it should be that all you need to do is
-- open datagram socket: UDP is connectionless, so no network activity
-- is required for this open - hence it will complete immediately.
-- the message callback is used to receive any replies to packets sent
over this socket
open datagram socket to lHostPort with message "gotReplyPacket"
...
on gotReplyPacket pOtherOne
mylog "Packet arrived" && paramCount()
repeat with i=1 to paramCount()
mylog i && ":" && param(i)
end repeat
end gotReplyPacket
(See the RevonLine example under alextweedly - UDP client and UDP server)
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: 07/07/2006
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution