
IP Communication
191
NetLinx Programming Language Reference Guide
When processing string data from a device, whether it is a regular device or an IP socket, the master will
attempt to copy this data to a buffer, if one has been created using the
CREATE_BUFFER
keyword, and
then try to run a
DATA_EVENT…STRING
handler for this device. If a
DATA_EVENT…STRING
handler
does not exists, Netlinx will run mainline to allow for any buffer processing that might occur in mainline.
At the end of a conversation with an IP device, there will usually be an incoming string event followed
by an offline event. The NetLinx master will copy the string to a buffer, if it exists, check for a string
event handler, run mainline if one does not exist, then process the offline event.
If you are processing that data in an offline event for an IP device, you will see a time delay between the
IP device or server closing the connection and the processing of the offline event. This delay will vary
with the size and complexity of mainline.
To eliminate this delay, simply include and empty string event handler in the
DATA_EVENT
section. This
will keep NetLinx from running mainline between the last incoming string and the offline event. See this
example:
DATA_EVENT[dvIP]
{
OFFLINE:
{
(* PROCESS THE DATA HERE*)
}
STRING:
{
(* DO NOT REMOVE ME! *)
}
}
Server Programming
Listening for client requests
A client gains access to a service by sending a request to the server specifying the port assigned to the
service. For the request to be acknowledged, the server must be listening on that port. To do this, the
server calls
IP_SERVER_OPEN
. This opens the port and allows the server to listen for requests from
client applications.
IP_SERVER_OPEN
requires the caller to supply a local port number. This local port number is a virtual
port, as opposed to an actual physical port on the server. When TCP is the transport protocol, the local
port represents a single client connection on the server's physical port. When UDP is the transport
protocol, it represents a single point where all client requests on the associated port are routed.
The local port number is the key to identifying data sent to or received from a client application. A local
port number may not be used in another call to
IP_SERVER_OPEN
,
until
IP_SERVER_CLOSE
is called
for that port number. The syntax:
IP_SERVER_OPEN(LocalPort, ServerPort, Protocol)
Parameters:
LocalPort
: The local port number to open. This port number must be passed to
IP_CLIENT_CLOSE
to close the conversation.
ServerPort
: The port number on the server identifies the program or service the client is
requesting.
Summary of Contents for NETLINX PROGRAMMING LANGUAGE
Page 15: ...Table of Contents xiii NetLinx Programming Language Reference Guide...
Page 16: ...xiv NetLinx Programming Language Reference Guide Table of Contents...
Page 18: ...Introduction 2 NetLinx Programming Language Reference Guide...
Page 76: ...Language Elements 60 NetLinx Programming Language Reference Guide...
Page 106: ...Combining Devices Levels and Channels 90 NetLinx Programming Language Reference Guide...
Page 112: ...Master To Master M2M 96 NetLinx Programming Language Reference Guide...
Page 182: ...Reserved Identifiers 166 NetLinx Programming Language Reference Guide...
Page 204: ...NetLinx UniCode Functions 188 NetLinx Programming Language Reference Guide...
Page 244: ...Appendix B Glossary 228 NetLinx Programming Language Reference Guide...
Page 245: ...Appendix B Glossary 229 NetLinx Programming Language Reference Guide...