Having a hard time understanding the MSDN documentation on the IP Helper Functions. Whats the difference between an adapter and a network interface?
An "Adapter" is a piece of hardware.
A "network interface" is a software construct.
Usually, there is one network interface per adapter.
But there may be network interfaces which are not from an adapter.
And there may be multiple interfaces per adapter.
The MSDN docs are quite large. Here is a quote from the Managing Interfaces section that might help clear things up:
There is a one-to-one correspondence
between the interfaces and adapters on
a given computer. An interface is an
IP-level abstraction, whereas an
adapter is a datalink-level
abstraction.
Related
Recently, I created a lightweight wrapper for the C++ boost asio library for some network communication. I used it to prototype some new functionality. We quickly moved over to a system that utilized Kafka to take advantage of an existing microservice framework when more internal funding came our way. No problem, I figured we would move to a different network model later on, and the internals were more important to my job than the network communication.
My question is, with the amount of technologies that abstract away network interfaces, (i.e. Kafka, grpc, ActiveMQ, ZeroMQ, etc.) are the use of base TCP/UDP sockets becoming more of a last resort, where software architects try to find an existing broker/stream processor/network message passing tool to fit their model? Or are there still many new production developments utilizing base level TCP/UDP sockets, not including those who solely write network libraries such as those mentioned above?
Note that I don't work with Kafka, grpc etc. in my line of work, but I have used UDP/TCP sockets extensively in the past. So forgive any misunderstanding of those particular technologies.
Question background:
My MFC CAsyncSocket-based socket code has worked fine in the lab for a long time, until it didn't (see how to determine socket interface type). It's design was based on the Microsoft Docs sample code which sequentially walks through a linked-list of socket interfaces keyed on socket family (like, AF_INET, AF_INET6, etc). With Remy Lebeau's answer to my question, I am now able to list the details of any interface my users might encounter. But as Remy points out there are MANY MANY interfaces out there. "Out there" is quite broad for me since my architecture is that of a dApp (aka, no servers), meaning I won't know my user's precise interface environment in advance. That leaves me with an interface selection design problem.
My question:
How do I select an interface when I don't know the interface environment of virtually all my potential users? There are potential indicators like an interface's Description or Friendly Name I could use to narrow down my selection resolving code. There is an interface structure member called IfType defined in ipifcons.h which contains 281 types. I could perhaps choose a subset from these. There is also a GetBestInterface function, but I don't know if that would work all the time or what its intention is.
I am looking for some guidance on this issue.
This is a newbie question .. Is there a way to sniff out sensor packet data from the SCADA environment? Any suggestions to proceed?
In general the answer is "yes, there is a way of getting data out of your PLC." The mechanics of the way will depend on your environment. The SCADA server may have an OPC interface for querying things. The PLC will likely have some protocol interface where you can query things, for example using Modbus.
How to proceed: Read the documentation for your PLC and your SCADA environment and see what interfaces you have available.
I have opnet 14.5 I am trying to find a Mobile Node with dual interfaces one for 802.11e (WLAN) and the other for 802.16e (Wimax) but it seems it is not there do opnet 14.5 has this node if no do I need special License ?.
thanks,
I would build a custom mode using OPNET Modeler with both interfaces in the model. You will have to design the connections and rules. Is it supposed to be a crossbanding relay or bridge or is it supposed to be a single endpoint node (like a computer) that acts as a source and sink only? Those are the questions you need to consider. If the latter case and you have a wired+wireless model, you might try replacing the wired interface with a WiMax interface, resulting in two transmitter/receiver pairs (WiMAX vs. WLAN). I'm not sure about the licensing (you will probably need Modeler + their wireless license among their plethora of license types), but I'm sure Riverbed/OPNET customer service will be happy to assist.
Is there any known effort to build a generic software framework/library for building distributed/P2P systems on the wider internet[1]? Something that ideally should provide basic services such as peer autodiscovery, autoconfiguration (wrt NAT/firewall issues, bootstrapping), fault-tolerance (churn-resistance, adaptivity, replication), differentiated transports (reliable, unreliable, unicast, anycast, multicast, broadcast), basic storage (DHT-like) and events notification (pubsub).
So, basically something like Hazelcast but not limited to walled-garden server-to-server applications. This would be tremendously useful to easily build distributed applications.
[1] with "wider internet" I mean the public internet, including mobile, residential, eventually connected and possibly byzantine endpoints
you will find different option and technologies depending on the framework you want to use.
For instance for Java based applications you might want to have a look at the JXTA technology.