Tibbo GA1000, User Manual

Page: 310 / 560

294 Platforms
©2000-2008 Tibbo Technology Inc.
Whenever the socket is engaged in the connection you can check the parameters
of the other side through three read-only properties-
sock.remotemac , sock.
remoteip , and sock.remoteport . For UDP, you can also check if the datagram
you have received was sent to your device exclusively or it was a broadcast- the
sock.bcast will tell you that. For TCP, you can additionally check if the socket is
in the "regular data" or HTTP mode- just check the sock.httpmode property.
There is an intricate detail to understand about the sock.remotemac, sock.
remoteip, sock.remoteport, and sock.bcast properties when you are using the UDP
protocol.
With UDP, your socket may be accepting datagrams from several different hosts.
As will be explained in
Receiving Data in UDP Mode , the most common way to
handle the incoming data is through the on_sock_data_arrival event. You will
get one such event for each UDP datagram that the socket will receive. If you
check the sock.remotemac, sock.remoteip, sock.remoteport, or sock.bcast from
within the on_sock_data_arrival event handler you will get the sender's data for
the UDP datagram currently being processed.
On the contrary, using sock.remotemac, sock.remoteip, sock.remoteport, or sock.
bcast property outside of the on_sock_data_arrival event handler will give you the
data for the most recent UDP datagram received into the RX buffer of the socket.
This is not the same as the next UDP datagram to be extracted from the RX buffer
and processed by your application!
Checking current interface
Starting from V1.2 , the sock object provides an additional property -- sock.
currentinterface ( not supported by the EM202/200 (-EV), DS202 platform)
-- which tells you which network interface the network connection is going
through.
More On the Socket's Asynchronous Nature
In Establishing Outgoing Connections and Closing Connections topics we
have already touched on the subject of the sock object's asynchronous nature. This
topic offers further details on what that means for your application.
Executing sock.connect , sock.close , sock.reset , or sock.discard method
does not mean that your connection gets established or terminated by the time
your program reaches the next statement. Executing these statements merely
instructs the Master Process what to do with the connection (more on the Master
Process in the
System Components topic). Connection establishment/
termination can take some time and your application doesn't have to wait for that
to complete.
Checking Connection Status topic explained how to find out actual
connection status at any time (see sock.state and sock.statesimple read-only
properties).
There are certain situations when your program has to take the above into
account. Here is one example. Supposing, we want to know the MAC address of a
remote device to which we are establishing an outgoing connection. Naturally, we
can do it this way:
348
347 348
328
334
303
342
331 134
287 290
330 328 348 331
7
292
355 358