Initial connection of Socketed components

[Guest]

I am new to both sockets and Netcf.

My task is to move an instrument controller module (called an ICE
implemented on a ICE.dll) down into a Pcb that supports Netcf. At present at
the Desktop level it uses Remoting to communicate with another application.

After reading various articles, the Msdn and this newsgroup I believe that
Sockets would be a good choice for us since Remoting is not supported on the
Netcf.

We manufacture analytical instruments for chemists (ICP's, Atomic Absorption
spectrometers, etc). Each will include a WinCe with an ICE to control it.

There can be 1 to N ICE's on each Pcb (though it will usually be 1). All
ICE's are controlled by a central component called the MIM (implemented as
MIM.dll).

The ICE's will only communicate with the MIM not with other ICE's.

I have created feasibility Apps that connect a desktop App to a Compact App
using sockets. When I do this I determine the Ip address manually. Since the
Ip on the setup I have is assigned by the local Lan box (a LinkSys box) it
may vary depending on startup sequence. Also the desktop will vary for the
same reason. Furthermore, in actual operation a User may not use a LinkSys
but have his desktop connected to a company Lan. In some other cases there
may be no Lan at all. Just the desktop and the instrument.

The question is how do I determine the Ip of the ICE running on a WinCe Pcb
from the desktop without privous knowledge? How does the destop and WinCe
pcb's intially connect up? Do you use a general broadcast of some sort. Is
there a way to set the ICE running on the WinCe Pcb from the desktop at power
on, keeping in mind that it can't be the same Ip for each Pcb since the MIM
could be connected to 1 to N ICE's on 1 to M WinCe Pcb's.

Also again how do you handle the situation where there is no Lan, just a
desktop, a hub and 1 to N ICE's on 1 to M WinCe Pcb's?

Appreciate any help, suggestions or code samples.

--John

 

[Paul G. Tobey [eMVP]]

There's no one answer to how to determine the address (in fact, there's
seldom a really great answer in any specific arrangement). When will the
address be assigned to the device and by whom? If this is something that
will be going through the IT department, they'll generally assign an
address, statically, and that will be the address of the device until
further notice. If that's the case, you might simply have a little central
repository somewhere which the PCs can query to translate a name into the
IP. For that matter, you might even have a DNS server that is local to the
network and tell it that, hey, this device, called whatever
(gaschromo1.mynetwork.org), is assigned this address. Then, you can just
use gethostbyname(), the standard socket call, on the PC to get the IP
address via DNS (your local DNS server would have to be in the list of DNS
servers for the PC, of course).

You could, if you want to, arrange for some broadcast method of getting all
of the device IPs in your area from the PC. You could do this with a
multicast group, too, if you wanted to. The PC could send a multi-cast
packet to a given group which each of the Windows CE devices would join on
startup and, when they received such a packet, they could individually
connect to a well-known port on the PC and send it their information.

Universal Plug-and-Play is another way that you might be able to do device
discovery. It's a COM-based protocol, though, so it doesn't mesh well with
managed code, at this point. But, you could use it, from a C++ program on
the PC, to discover the devices and then build a list in a local database on
the PC (or a text file, if you want), which your managed code could then
access to get a device list for presentation to the user (assuming that the
PC user will select which device to use and what to do with it).

If you have a network, of any size, then you *do* have a LAN. That is, if
my PC is connected to a hub, I have a LAN, even if there's nothing else
plugged into the hub (it's not a highly useful network, maybe). If you add
one of your devices by plugging it into the hub, you still have a LAN and
your PC and the device can communicate with one another. Sockets will work
fine in that situation.

Paul T.

 

[Guest]

Thanks on the Ip identification.

On the other two questions--
1. On team would like the ICE's and the MIM to run on either Netcf or Net.
Since the projects and Reference's are different for Netcf and Net it would
appear to mean that we will have to have two source code tracks.

The question is it possible for Exe's and Dll's meant for WinCe Netcf to run
on the desktop as well as on the WinCe pcb?

If not is there another away to avoid maintaining two separate but
synchronized code bases?

2. The desktop version uses Remoting to communicate between parts of the
system. Remoting is not available on Netcf. Remoting offers events which we
use at the desktop level.

Are events part of the socket functionality or do you simulate then using a
separate thread to listen for incoming traffic, signalling the main thread
when something has arrived via the socket?

--
John Olbert

There's no one answer to how to determine the address (in fact, there's
seldom a really great answer in any specific arrangement). When will the
address be assigned to the device and by whom? If this is something that
will be going through the IT department, they'll generally assign an
address, statically, and that will be the address of the device until
further notice. If that's the case, you might simply have a little central
repository somewhere which the PCs can query to translate a name into the
IP. For that matter, you might even have a DNS server that is local to the
network and tell it that, hey, this device, called whatever
(gaschromo1.mynetwork.org), is assigned this address. Then, you can just
use gethostbyname(), the standard socket call, on the PC to get the IP
address via DNS (your local DNS server would have to be in the list of DNS
servers for the PC, of course).

You could, if you want to, arrange for some broadcast method of getting all
of the device IPs in your area from the PC. You could do this with a
multicast group, too, if you wanted to. The PC could send a multi-cast
packet to a given group which each of the Windows CE devices would join on
startup and, when they received such a packet, they could individually
connect to a well-known port on the PC and send it their information.

Universal Plug-and-Play is another way that you might be able to do device
discovery. It's a COM-based protocol, though, so it doesn't mesh well with
managed code, at this point. But, you could use it, from a C++ program on
the PC, to discover the devices and then build a list in a local database on
the PC (or a text file, if you want), which your managed code could then
access to get a device list for presentation to the user (assuming that the
PC user will select which device to use and what to do with it).

If you have a network, of any size, then you *do* have a LAN. That is, if
my PC is connected to a hub, I have a LAN, even if there's nothing else
plugged into the hub (it's not a highly useful network, maybe). If you add
one of your devices by plugging it into the hub, you still have a LAN and
your PC and the device can communicate with one another. Sockets will work
fine in that situation.

Paul T.

 

[Paul G. Tobey [eMVP]]

1. Yes, you can run .NET CF executables on the desktop. You can't do the
opposite.

2. No, sockets don't support high-level abstractions over themselves. They
are like a pipe or a stream of bytes. The sockets attach no meaning at all
to the content data in the stream. Whether 'something arriving' means the
same as an event to you or not, I can't tell. My guess is that the 'event'
in your other code is merely one type of information passed around. If
that's the case, whatever part of your .NETCF code parses the data coming
through the socket would have to decide, "Hey, this data indicates that the
other end of the connection is trying to notify me of some event", and do
something appropriate.

Paul T.

Thanks on the Ip identification.

On the other two questions--
1. On team would like the ICE's and the MIM to run on either Netcf or Net.
Since the projects and Reference's are different for Netcf and Net it
would
appear to mean that we will have to have two source code tracks.

The question is it possible for Exe's and Dll's meant for WinCe Netcf to
run
on the desktop as well as on the WinCe pcb?

If not is there another away to avoid maintaining two separate but
synchronized code bases?

2. The desktop version uses Remoting to communicate between parts of the
system. Remoting is not available on Netcf. Remoting offers events which
we
use at the desktop level.

Are events part of the socket functionality or do you simulate then using
a
separate thread to listen for incoming traffic, signalling the main thread
when something has arrived via the socket?