Echelon LNS - Manual (Page 332)

LNS Programmer's Guide 318
Registering a Mobile Application
Mobile network tools should set the PingClass property of their
NetworkServiceDevice object to either PingClassMobile or PingClassTemporary.
Use PingClassMobile if your application is a permanent part of the network (i.e. it will
always be somewhere on the network), but may move from place to place. The LNS
Server checks for the presence of mobile devices at the highest frequency, by default
every minute.
If your application is just being attached to the network for temporary use (as may be the
case for a maintenance tool), use PingClassTemporary. The Object Server checks for
temporary devices at a slightly lower frequency, by default every two minutes.
Moving a Mobile Application to a New Channel
The steps you must take when moving a mobile application from channel to channel
depend on whether it is a remote or local LNS application.
If your application is running locally, then it must tell the system that it has moved so
the LNS Server can update the Network Service Device’s network address to be
consistent with the new channel. This is done by calling the PreMove() method , and
then calling the PostMove() method. The PostMove() method must be invoked after
the device has physically been moved.
If your application is running as a remote Full client, you should not use the PreMove()
and PostMove() methods in this fashion. This is because the application would not be
able to invoke the PostMove() method after it has moved, since intervening routers may
not pass on the messages in most cases. Instead, the application should re-attach itself to
the network by closing the system and network, and then re-opening the network and
system after the device has physically been moved. During the open, the LNS Server will
implicitly invoke the PreMove and PostMove methods to move the NSI along with all of
its connections to the new channel.
If your application is running as a remote Lightweight client, there is no need to do
anything when moving the application. Since the Lightweight client uses the same
Network Service Device as the LNS Server, its location is irrelevant to LNS.
Multi-Threading and LNS Applications
LNS uses Single-Threaded Apartments (STA) only. It does not support Multi-Threaded
Apartments. This means that client threads that access LNS are created as STA threads
only. If you are developing an LNS application using Visual C++ or Microsoft Visual
Studio .NET, you must create the threads that will access LNS in a Single Threaded
Apartment.
If you are using Visual C++ or Microsoft Visual Studio .NET and want to write an
application that will use multiple threads to access LNS, each thread must initialize
COM as an STA thread. You will need to marshal the object references received from
LNS in one thread to any other threads the application is using.
If you are using Visual C++ or Microsoft Visual Studio .NET, you can set the
lcaFlagsDirectCallback
flag in the
Flags
property of the Object Server to use direct
callback within your application. When using direct callbacks, all event handling