Networking
Simulation works in many of the same ways as commercial games--both strive to exchange data, and both of them exchange data via networks. Games are meant to be fun, while simulations seek to train. Ultimately both commercial and simulation applications use networks for the same thing: achieving fast exchange of information. That's the objective of DIS sent over TCP/IP networks.
Transmission Control Protocol/Internet Protocol (TCP/IP), mentioned earlier and discussed in more depth here, is the most common tool to exchange information. Almost all computers have a TCP/IP interface, from desktops to laptops, mobile phones, videos, watches, and home furniture. The military has some other things in addition to TCP/IP, including radio connections such as LINK-11 or LINK-16. The uses of radios are complex in their own part, but we'll ignore them for now. A big, complex pile of software, hardware, and custom applications exist in a collection we sometimes call "Gateways". We'll talk more about that later and concentrate on programming in TCP/IP right now.
Many programmers have some training with TCP/IP before starting--often TCP/IP programming is used in other applications, but that is not the context TCP/IP context of a DIS program. Likewise, not all system administrators are aware of what practical TCP/IP DIS networking issues exist. This may give an audience from each group a chance to learn something.
This subject can help DIS users understand basic question ranging from TCP protocol sockets and UDP protocol sockets that freely drop packets, and do it in several languages. Programs can use TCP sockets along with unicast, broadcast, and multicast networking. In the modern era multicast is very commonly used. This may change if they use the implementation of WebSockets and WebRTC in a smaller application.
Transmission Control Protocol/Internet Protocol (TCP/IP) is a software standard that has been developed for decades and is today installed on nearly every computer. "TCP/IP" is term that refers to an entire protocol; "sockets" are one way to communicate. Different "UDP Sockets" are the other popular method, while "TCP Sockets" are a similar technique.
TCP/IP can be a complex affair, but this tutorial will attempt to be as simple as possible. If you wish to learn more about the subject, two good books are The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference, by Charles M. Kozierok, TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition), by W. Richard Stevens. Again, that’s if want to learn more. Today there are many web sites that explain network communications over TCP/IP as well. This includes implementation libraries that make the programmer’s life easier. Very often these days you can run many virtual hosts on one laptop. To me, it's likely to shift from individual pieces of hardware to Amazon Web Services or another Cloud asset.
Almost everything is done over TCP/IP, a framework for communications between devices. Note that TCP/IP is a software concept, independent of hardware. TCP/IP runs on all sorts of different media, including Ethernet wire, fiber optic, and wireless. An illustration is below:
Networks
We send messages from one to other hosts. For example, we could run an application such as Chrome or FireFox to contact a server running on http://www.nps.edu, or http://amazon.com. The example of the three computers above could be sitting on one table sitting in a lab, or the applications across the world. That means we need a way to uniquely address a host. And it means it means we should address several completely different applications running multiple applications running within a host. It may be that we have our application, but it also needs a www host and an email servers. We'll discuss how to send messages in that way: an address that describes a unique value for the address at the computer; with what's called a port; and how to translate a unique value to a name, such as "www.nps.edu" or "amazon.com".
Each host in a TCP/IP network needs an address at which it can be uniquely addressed. I'll drastically simplify the discussion; things have become complex in the last 30 years as computers have become cheap and numerous.
TCP/IP (version 4) has a 32 bit, 4 byte long address. Four bytes seems to have over 4 billion slots initially, but it's not true even up to that level. The TCP/IP version 4 seemed huge when it was adopted back in 1983, when there where hundreds of computers in the network to be differentiated among. It seemed to be silly-large in 1983, but it's not so with PCs, workstations, phone devices, commercial applications, and more. The IPv6 version uses a 128 byte version, and is still being deployed, but most all applications are made to (somewhat) use IPv4.
You can think of the Ethernet computers above to have TCP/IP uniquely assigned to it.
Networks
You've probably seen addresses such as 192.168.1.10 in your home. Your daughter's laptop will have an address such as 192.168.1.2 while yours will be 192.168.1.5 and the printer 192.168.1.7. You should view a group of computers working together as a network controlled by a single person. You "control" the 192.168.1 group of IPs and what machine is given what number, the first three bytes of the four bytes of the total IP number. The assumption is that you've been assigned the group of the last byte 192.168.1.0-255. (With some exceptions.)
You can easily discover the IP number assigned to your laptop. On Apple devices you can typically look at System Preferences->Network->WiFi->Advanced->TCP/IP. Windows 10 works in a similar way.
You'll recall that TCP/IP IPv4 is four bytes (or 32 bits) long. There are several ways to interpret this. The value "11000000.10101000.00000001.00001100" is a binary, zero or one value that sets every value of an IP. You change this if you like by changing all the zeros and ones too much more memorizable decimal numbers. It turns out that the "11000000.10101000.00000001.00001100" number can be equally well represented as "192.168.1.12". The bottom 8 bits "00001100" are a binary representation of "12", and so on. Remember that with 8 bits turned into decimal values, we can get from 0-255. We can't get a value of "417.287.312.586" in between if we have only 8 bits to represent the value. Nor would "205.17.15.280", because anything above 255 doesn't have enough space to take only 8 bits. (Take your web to https://www.rapidtables.com/convert/number/decimal-to-binary.html if you want to convert yourself.)
If we want to address another host we need to specify what the IPs we saw above a host specify. The above example of 192.168.1.12 is one thing we have use if we're trying to access an application at 192.168.1.42. Each is uniquely identified, let's say at 205.155.65.12. At this time it is the how did that happen? How'd the different Ethernet connections get different numbers?
It depends.
It's possible to go to every machine, bring it up, type an IP number such as 192.1.1.23, which is known by you to be different from other hosts. It's possible. It's valuable in a few instances.
You've probably done something differently in your own home, or often at work. You've probably had a wireless base device, just as that below. The same applies to groups of Ethernet.
Devices to Assign IPs
The device starts up, then starts listening at the very low level for how to assign the IP number not held by anyone else. If it's your laptop it may assign 192.168.1.28 to it when it starts. You don't have to assign your own IP at all. In your home, it's done for you.
The interesting thing is that this is always a limited time. The IP is not given out not for a lifetime. The wireless home device (a wired Ethernet service works the same way) accepts it, but when it does so it can start offering a limit for how long it will last. If your host does not respond for a long enough time the IP is recycled.
You'll notice that your IP is very often something like 192.168.1.12. That seems to happen often, with 192.168.x.x. It's different from every other host in your home, and usually but it may be the same as your neighbor. Sometimes you see 10.x.x.x. How did that happen?
We used to supply IPs to computers because worldwide we had theoretical limit of around 4 billion of them. That turned out to be no where close to meeting demands. Originally there would a fixed IP range, as from 131.120.17.0-131.120.17.255. That's about a total (theoretical) of 255 hosts. But of course they can't make it inflate to be 1024 hosts, because the limit of the network originally couldn't be expanded in the same range. Our newly expanded application needs IPs that seem to start in the same range.
Instead, your home system uses the single IP your user has given to you. Your LinkSys or equivalent devices contacts the single IP.
When your game laptop tries to contact your wife's game laptop, the two are on the same networks. They both got the IPs assigned by the same LinkSys, so the two of them know how to send messages to each other. If you want to exchange messages with your wife, you can do that directly with something like 192.168.1.12. But it won't contact your neighbor, who maybe also has a laptop with 192.168.1.12.
The key is for the LinkSys IP to make use of the one IP assigned to it. Your IP uses the 192.168.1.12, but uses the IP assigned to the device. When your laptop sends a message to a remote machine, such as the machine at 205.155.65.12, there's another substitution of your origin. The LinkSys substitutes its own, single IP, provided by its own provider. The LinkSys gets one for IP itself, and provides as many for the local hosts as it wants. Of course you may have individual machines with multiple Ethernet devices as well; there could be a servers that run across four separate cables with different IPs, for example.
The local IP range context differs--192.168.0.0 to an extent. You can read differing views at https://tools.ietf.org/html/rfc6890, if you want more precise descriptions of 192.168.0.0, 10.0.0.0, and other IPs. As a good procedure, don't. (https://www.lifewire.com/private-ip-address-range-818387)
At the above point was get assigned an IP to a unique way to things. It's not very realistic to train users to type in http://205.155.65.12 instead of http://www.nps.edu, but it's also realistic way to see where the IPs really are for you at home. No one can remember four numbers (plus other data) into turning a web data into a realistic system, or any simulation system that uses only IPs instead of names.
First of all, you can a utility called nslookup on Windows, Mac, and Linux installs. In some places they have not been installed in "Pro Windows". Otherwise its and installed problem, and it's somewhat deep to find the solution.
You can Mac and Linux using "dig" DiG Howto if you'd like to use them more to use that the nslookup utility. You can install them via Mac https://brew.sh/, CentOS via yum, and Ubuntu via a sudo apt-get install dnsutils
Run it on the nslookup command line using like this:
nslookup
In is this one it will happen to be faulty with a command "** server can't find http://www.nps.edu/: NXDOMAIN". I like to copy-and-paste. It works out for me poorly, and will out for you poorly as well, because I included "http://" as an inclusion to the nslookup. Stick strait to the IP. billy.nps.edu will also happen to see www.nps.edu, both names resolving to the same 205.155.65.12 IP devices.
The Widows Setup profiles if you some setups for windows commands.
The dig utility is that running in Mac and Unix, and occasional Windows, like the following:
DiG
You can supply your own configuration file that matches IP devices, such has 192.168.1.15, to names, such as "helo1" on the local network. You can configure by typing in "helo1" of 192.168.1.12, "helo2" to contact 192.168.1.13 in the same configuration, and so on.
Now you can add an add a way to attribute a name to a number. Remember, we can review an IP layer called 192.168.1.40 with a name we now call "M1A2" or "IronHorse". It will naturally split either "M1A2" or "IronHorse" to 192.168.1.40 or 192.168.1.50.
We used to do that with single configuration definitions defined at every level, from individual to every one. One definition on every host receiver has usually called /etc/hosts on the receiver even if receiver was different that the others. It looks like this:
/etc/hosts
The history of the positions is at wikipedia shows the position of various standards, including Microsoft Windows. (In Windows this is often at C:\Windows\System32\drivers\etc\hosts; it Macs is often at /private/etc/hosts; and Unix is usually at /etc/hosts.)
This is pretty good, so long since no one makes no one makes a single mistake as millions of names of hosts are configured to the names of IPs as we manually configure names to IPs. Typing hundreds of millions of names and numbers into every machine is not very practical. We want to create an automated, limited tool that depends on themselves rather than ourselves. We can depend on amazon.com name on an assigned IP of 176.32.103.205; they're ultimately responsible for what's right, not ourselves.
That's called Domain Name Service (DNS).
You've got a DNS is installed on a machine. The DNS machine may appear in the background when it is also handing out IPs to those with that are not assigned to them. It looks like the below, so simplify:
Simple DNS
This is the most simple DNS example. The DNS example is in this case at the very low level, and can issue an IP to reach wired, fiber net, and Ethernet host on your own network. You have to point your DNS example, not have your /etc/host each change on every host.
A more complex is with more both "DNS devices" with the ifconfig to also see what else on the current machine is up:
ifconfig
This is a Mac that can make use of its use of ifconfig; right now, only one wireless config at the listed at 192.168.86.33, and one very interesting script of 127.0.0.1.
The 127.0.0.1 is consistently used on every single TCP/IP host. It doesn't need any DNS, because every single host running is required to refer to their own hosts as 127.0.0.1. That allows you need a host to communicate with yourself, and only yourself, by using 127.0.0.1. You can't contact an amazon.com through 127.0.0.1.
Right now the aspects scan sensibly can use 192.168.86.33 can be used to reach other machines with a name. Maybe you've named it "airplane15", and it's running as a web browser. At the top level you'll you can directly aim that the browser will process "airplane15" by the local conversion DNS to convert it to an IP. Recall, you can can also have different networks as the if shows the different ifconfig results.
This gets broader as you get out of your own network. We're trying to get get, say, amazon.com from inside your own home machine. Recall that you were trying to get all configured names to our own, public IP. Your own device connects to the public network; it doesn't depend on 192.169.86.x. We don't initially set or even know what amazon.com is. Instead the DNS uses it to swap the old destination address with a new one.
The image is below:
DNS Representing Amazon
You can imagine other host requests the amazon.com DNS server. Amazon.com has many thousands of queries from other DNS machines and hosts, from oregonstate.edu, nps.edu, or your home release. We send the amazon.com DNS request; they'll send back the IP.
Our local DNS can keep the correct IP for a while. The IPs where the are wanted and they are cached and remained. Amazon can choose to remain off other IPs for some period, for example; it may last for five minutes or five weeks depending on what the DNS server believes. What's more, they can return results based on East or West coasts to you, which depends on shipping.
The other thing you need to become answered: how are IP names handed out to DNS entries? Recall our IP is limited by a theoretical range of 32 bits, and we need a limited access to it. (It theoretically also treats IPv6 as well.)
At some point we contact the group that owns it, named for example www.rockstargames.com or http://www.iitsec.org/. They owners can add www.rockstar.org to any IP they'd like.
whois.org
This can also be shown by the organization to distribute DNS IP names. In this case, the names NS43.WORLDINC.COM and NS44.WORLDINC.COM, the DNS names, are are present as well.
Another use of whois in on the Mac and most Unixes. (Try that yourself.)
Naval Postgraduate School
Notice the public DNS traffic server always is provided to others? You can see this at https://www.verisign.com/en_US/security-services/public-dns/index.xhtml has this, as long as is not outdated.
The first options are given to it by the your early DNS servers running. The
This where your computer to the local DNS server is running. It has some effort to start if up; you can start a DNS server with thirteen "root name servers" in them. https://en.wikipedia.org/wiki/Root_name_server is the https://www.iana.org/domains/root/servers. These are below:
Root Servers
There are more actually kept than single ones than that, scattered around the US and the world.
Once upon a time there was a limit to .com., .edu., .gov., .mil., .net., and .org. in the US. Sort of. Those had a those had an absolute domain name to begin looking up DNS results, but a limited results. The real names had seven ending names, starting with things like nps.edu, mit.edu, and stanford.edu, or nintendo.com, epicgames.com, and idsoftware.com. The thirteen DNS names returned things like the owners of the companies, and at least more importantly the location of at least two DNS for every single name.
It only does not work for putting in a DNS limit for matching looking up DNS entries. See http://www.dns-sd.org/trailingdotsindomainnames.html.
There is no seven starts to the beginner these days. It's a few thousand limits that are out there beyond seven if applied to the early staged.
These have names registered with names given to you handed IANA at least two DNS servers. These have to define correct issues like what DNS for things are for that once were .edu, .com, and .org a few years earlier. The "edu" DNS gave you "nps,edu" and the DNS entry, the "org" would have the "movesinstitite.org" entry org served up from ".org", The They're at https://www.internic.net/domain/named/root
Unsuspected To-Level Names that Work Out
You can see the https://www.iana.org/domains/root/db
We can see the final feature of DNS:
How Layer DNS Work
At last, we know how it works. A new DNS starts up, and it installs the thirteen DNS with the from the root standards. Your own DNS knows a little about names and IPs now--not all the data in them, but how to reach all data if they need it. They know nothing about www.nps.edu or www.marines.mil, but if they want to get it, load the thirteen standards from . As soon as you load www.marines.mil you can get the .mil DNS sever--there are (theoretical) marines.mil, army.mil, and af.mil out there. Your new DNS can connect to the marines.mil DNS, and you find out what the www.marines.mil IP. If you ping it you can pass in the www.marines.mil and get back 104.70.217.137.
The DNS place a limited time on the IPs and names, and the differences can change. They may place coverages based on how fast the DNS loads the IP; for example; or they think Marine recruits might be in Alaska, the single IP of the servers in Florida, and that could be a good practical change to another WWW site with a different DNS result in Alaska.
In other nations there are different groups that use other nations to be issued IPs. The US got a lot of IPv4s and the others got IPv6's. The site shows https://www.iana.org/numbers is a good example for RIPE NCC (Europe), LACNIC (South America), AFRINIC (Africa), and APNIC (Australia, New Zealand, China). Although China runs its own DNS site with its own data. (https://public-dns.info/nameserver/cn.html)
There's a lot of complexity of DNS. I've always had to provide answers because nobody likes my primitive answers.
The illustration below shows the essentials of a four-layer interpretation of the TCP/IP protocol.
TCP/IP Protocol
The top layer, the Application Layer, is written by the code simulation programmers. Each language includes both code for sending and receiving DIS messages and the simulation program itself. You can place TCP or UDP sockets in your code, and you can arrange to have your software send and receive data. The Java, C++, C, Objective-C, and so on languages have different APIs. Also, the same language can have different APIs on different operating systems. The Microsoft API for your programs making network calls is not quite the same as the Unix API. It requires a programming labor effort.
The Transport Layer and how we talk to TCP/IP and are the most important aspect. If lucky, we can largely ignore everything below the Transport Layer. The Application Layer is where we implement the DIS protocol and the simulation itself.
The Internet Layer is responsible for changing large collections of data into smaller packets that can be routed and transmitted across the network. Very often it can be ignored by the DIS programmer.
The bottom layer, Network Access Layer, is related to the type of network transport used. The bottom layer may use 802.11 wireless networking, or may use gigabit Ethernet, or it may use 10 gigabit Ethernet. The interesting thing is the application can use any of these network types without changing code. An application uses the Transport Layer API, and the layers below that can use slow wireless or fast Ethernet. Our simulation application can use either.
There are more than one set of features that can be used to exchange messages between hosts. These include Transmission Control Protocol (TCP) sockets, and User Datagram Protocol (UDP) sockets, and within the UDP sockets the additional technologies of broadcast or multicast can be used as well. The API layouts are shown in the graphic below.
TCP is technology to communicate data between hosts, and it has both some advantages and disadvantages when compared to UDP.
A TCP protocol networking socket is a stream-oriented connection between two hosts, and two hosts only. A single TCP socket cannot send a message to a dozen different hosts. Instead there must be a separate TCP socket from our host to each of the dozen other hosts.
We can send a continuous stream of data. The connection is full-duplex; messages can travel both directions between the hosts at the same time.
TCP sockets are responsible for transmitting reliable streams of data. This can be both appealing and limiting.
Imagine sending a stream of hundreds of DIS Protocol Data Units (PDUs) to another host. What if the network has a problem, and drops a PDU? Or what if the receiving application crashes? Networks have a difficult problem delivering data reliably.
Imagine sending a copy of the Jane Austen novel Pride and Prejudice. It's hundreds of pages long. We want to send the entire novel. Even using ASCII text, this totals over half a megabyte of data. From a practical API standpoint the programmer can send the entire text of the novel with a single command to the Transport Layer API from the Application Layer. But below the Transport Layer TCP/IP has to break up the half-megabyte of data into smaller packets. Very often the packet size used is around 1500 bytes. Each of these packets is routed through the network, through dozens of devices. When the smaller packets arrive at the destination the receiving TCP socket assembles the smaller packets back into the large message sent.
What happens if a single message is dropped? If we are using TCP sockets, we don’t want to lose a single sentence from the Austen novel. We want a guaranteed delivery of the entire novel, undamaged, with every chapter in order. We want chapters from start to finish. This is what TCP sockets provide. TCP will detect the loss of a packet that makes up the entire message. It will cause the sender to resend the packet, and eventually the receiver will have all the packets necessary to receive the novel. If we are sending a series of DIS PDU messages, then each PDU will be delivered.
What's more, the sending side can't send chapter 25 if it hasn't received confirmation that chapter 12 was received. Remember, we want to receive the same stream of information. As far as the sender is concerned, it will continue to resend the message. That can take a lot of time, and it will cease sending more data. Chapter 25 can't be presented to the receiving application until chapter 12 has.
In the case of DIS, what happens if we have one PDU per message? In the case of TCP sockets having to resend a DIS PDU means no messages after that one will be delivered until resent. That's all done automatically by TCP/IP, but can slow things down.
TCP sockets have other features as well. TCP sockets can automatically lower or increase the speed at which they send depending on how capable the receiver is, for example. If we are sending to a slow mobile device from a fast workstation host, TCP sockets will find a usable send rate that does not overly challenge the mobile device. TCP sockets also always ensures that Austen novels are delivered in the same byte order in which they were sent, and ensure that there are no duplicated bytes in the message. The end result is that the receiver gets exactly what was sent by the sender.
Notice the “one recipient per TCP socket” restriction. If we have 10 participants in a NVE, and we want all nine other participants to receive a PDU, we have to send the messsage nine times across nine TCP sockets. If we have 100 simulation participants we’d need to send the same PDU 99 times.
We also have to worry about latency, the average time necessary to deliver a PDU from one host to another. What happens if the network somehow has a problem delivering a PDU when the network drops a packet? The TCP socket has to discover the loss of the packet after waiting long enough, and then resend it to make up for its loss. Remember TCP sockets also promise in-order delivery and reliable delivery. This means PDUs sent after the one that was lost cannot be delivered, either. The delivery of PDUs will simply stop until the lost PDU problem is fixed.
Do we always need a delivery of all PDUs? Not necessarily. Imagine a PDU that describes the location of a vehicle. A PDU that determines the location of the vehicle is sent every 1/30th to 1/60th of a second, about the frame rate of a 3D display game. What if one of these position updates is dropped? We’d have to wait long enough to discover its loss, then ask the sender to resend it. It would also stop the delivery of the rest of the position updates. That could make the movement of the vehicle worse.
TCP sockets are used in NVEs for several reasons. They can be used to send DIS PDUs, though designers should note the limitations inherent in the TCP sockets. TCP can be used for other reasons as well. A TCP socket can be used to download or transmit large files, such as terrain data or graphical data when the simulation starts. For these reasons and others knowing something about TCP can be useful.
Remember, sometimes libraries that hide Transport Layer API are used, and they make the programmer’s life easier. But the fundamental limitations of using a TCP socket are not changed, and the simulation application designer has to realize this.
UDP sockets are another API available to applications at the transport layer, just as TCP sockets are, but they deliver features that address the problems of TCP sockets above. Just as the API can create TCP sockets, we also have an API that can create UDP sockets.
UDP sockets back off on TCP socket features. TCP sockets offer continuous streams of data, no dropped information, delivered in order, and will slow down the sending rate if the receiver becomes overwhelmed. The TCP socket sender and receiver remain stream connected. UDP in contrast instead sends distinct, stand-alone messages. A UDP socket will accept a message of any content and then send that message to a destination. The UDP socket does not ensure that the message is actually delivered. If the network causes its loss somewhere, there is no attempt to resend it. For an application sending a continuous stream of messages, such as the vehicle position PDUs discussed above for TCP sockets, this is good. A dropped packet will no longer halt the delivery of following PDUs.
UDP sockets also do not insist on processing messages in the order they were sent. It’s possible that a PDU sent early will be delivered later. For our vehicle position reports this might seem to be a problem, but in fact it turns out to be an easy one to avoid. We can in the message contents simply include a sequence number, and drop any PDUs that are too old or out of order. This out of order detection is done by the Application Layer application (i.e, us) rather than the TCP socket, but it’s pretty easy to do.
UDP sockets back off on TCP sockets in streaming, reliable delivery, and in-order delivery. They instead deliver messages in indepenent messages, that can (but usually are not) be delivered out of order, or dropped entirely. Networks are usually reliable enough for UDP to work well.
UDP is useful, but as with TCP sockets the initial solution is to send one message to one host. If we have 100 participants in a simulation and we want to send a message to each, we have to send 99 messages, one to each address. This takes bandwidth, bandwith use that can increase with the square of the number of participants. What we’d like to do is instead send a single message that is received by all the simulation particpants. Using broadcast addressing is one way to do this. Broadcast addresses are a special IP from early in the development of the TCP/IP protocol. Though old, it’s still used in many places. It’s less capable than the multicast protocol discussed later, but it is used by some.
Using broadcast uses conventional UDP sockets, but with a special approach to picking the message destination. Every host has an Internet Protocol number assigned to it. The below shows the values for a host:
Apple Mac Network Display
As you can see, the host has an IP number of 10.0.0.158. There are no other hosts on the network with that IP. When we create a message to send to that host, we set a destination address of 10.0.0.158 in the message. If we want to send to another host, we’d have to send a new message with a different IP, such as 10.0.0.42. (Yes, you can also use a name if you are willing to convert a name to an IP, wich is usually easy to do.) If you wanted to send to 99 hosts you’d have to do this 99 times. But what if you wanted to send only one message, and have that received by everyone on that network that was interested? We can use something called broadcast addressing to do that.
An IP such as 10.0.0.158 actually has two parts: a network portion, and a unique host ID within that network. You’ll notice an item called the “subnet mask” that has a value of 255.255.255.0. An IP address is four bytes long, and each of the four period-separated numbers in the address is a separate 8-bit long byte. What is happening is that the subnet mask is defining the separating line between the “network portion of the IP” and “host within a network” portion of the IP. In this case, because the subnet mask is using 255, it means the first three bytes are part of the network, while the last byte is used to list individual hosts. The host IP we see is 158 within our local network–there should be no other host with that IP on our network.
What the early designers of TCP/IP did was pick a special IP to describe “This message is for any host on the network, not just one specific host.” In the case of DIS, sending to a broadcast address would allow us to send one PDU message instead of the 99 repeated messages. That’s a valuable reduction in broadcast use. lt So what’s the special IP address? It’s the host region of the address with all bits switched on. In our case, the first three bytes (10.0.0) is the network portion. Our host portion is set to the value 158. The broadcast address is 10.0.0.255. That’s what all bit values turned on in the host portion look like for an integer byte.
So long as all the simulation participants are present on same network, using broadcast can dramatically reduce the bandwidth used.
The source code at the links below show DIS packets being sent in a Netbeans Java program. One sends PDUs, while the other receives.
This github project demonstrates decoding DIS broadcast messages:
Java Receive and Decode DIS PDUs
And this Java program demonstrates sending PDUs.
Broadcast was used from early on, but in the mid-90’s a technology called multicast started to be used. Multicast is more powerful and flexible than using broadcast addressing.
Multicast uses UDP sockets that have been specially configured, and that use a special set of IP numbers. Any IP number in the range 224.0.0.0 to 239.255.255.255 is a “multicast address,” or group number.
Let's pick the multicast number 239.1.2.3, which is within the range mentioned above. We can (with a properly configured UDP socket) have a group of hosts subscribe to this address, while the rest of the hosts do not. With broadcast, every host on the network would be subscribed to messages sent to that address. In a network with 100 hosts, we might make only 20 subscribe to the address 239.1.2.3 for messages.
In our simulation application we may want to send out updates for the position of ships to other ships, and tanks to other tanks. We can set up ship applications to be subscribed to the multicast ship address, 239.1.2.3. Any message sent to that address will be handled by hosts that have chosen to be subscribed. Likewise the tank applications at the multicast address 239.1.2.4 will receive messages sent for tanks. The administrative application which wants to receive both tank and ship messages can subscribe to both 239.1.2.3 and 239.1.2.4.
Multicast is even more powerful because it is not limited to the local network. Broadcast required all the hosts to be on a single, local network. Multicat can, if configured correctly, include more than one network. For simulations, multicast networking can be used in a network that ranges across continents.
Multicast is the preferred solution over broadcast. Both broadcast and multicast are usually the preferred solutions over using single host addresses.
What if you want to run multiple more than one service, such as http or www, on a single host? We see this a lot, for example with a single host that keeps a DIS service, a DNS service, FTP, SSH, and a database. It's not enough to only separate based on IPs. We use what are called "ports" which give a single place for things to attach.
There are actually at least two stacks of ports, from zero to 65535, are in use. One stack for TCP sockets, and another stack for UDP. TCP and UDP sockets won't interfere with each other. These are different sockets. When we attach to a socket port, they are different; www.nps.edu running the web site can also be running a database with different ports.
The ports are specific to TCP and UDP, as said. There are big lists are at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml, or in the unoffical wikipedia of https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
There's lists for popular ports; 443 for encrypted connections to your encrypted web servers, such as the Firefox, Chrome, Safari, Internet Explorer, or Opera, for example, and port 80 for unencrypted communication. An example can look like this as a good way to test what's using a single port of what's going on. In fact, web servers don't have to rely on ports 80 and 443; we'll see later that they can relay or any ports, including 8888 and 8889 using other ports.
The http is a tcp protocol, not a udp protocol. That means in this case where we httpVsHttps.com will only be examining tcp protocols, and mostly 80 ports.
Look up the number via nslookup www.httpvshttps.com. (nslookup works on Windows 10 as well as Mac and Unix.) The IP may change from day to day, so look it up rather than relying on older DNS name lookups.
Lookup the IP for the Protocol
What we want to do now is use the socket tests on the http and https process. This uses the tcp protocol when you click on the http or https underlined items. Stick with http.
Lookup the IP
You can getting ports with by first clicking the httpVsHttps.com, clicking on the http order, then in a rapid test using "netstat -an" in a terminal. (netstat is in Windows and Unix as well.) We'll see a rapid for the most part a list of your own machine's connection to httpVsHttps.com.
As it's running, it rapidly generating several tcp sockets.
Lookup Tables
This shows the reality of ports on tcp. The "grep" is a system which will print only the lines that contain the content. "netstat -an | grep 45.33.7.16" will expose us lot less of data compared to netstat -an nps.edu. (If you want a lot of that can be tried with netstat -an nps.navy.mil.) By typing quick on the and getting netstat going quickly we got back five sockets to ourselves. The top one above is 192.168.86.33.56913 to 45.33.7.16.80.
Notice something? 45.33.7.16.80 is ending with .80, and 80 is the http port of web servers. It's what users will try to connect to. The user will use ports of their own, such as 192.168.86.33.56913. What's .56913? That's a port picked randomly by the TCP/IP to connnect my machine, at 192.168.86.33. The others are 192.168.86.33.56912, 192.168.86.33.56911, 192.168.86.33.56907, and 192.168.86.33.56906.
(There was one number that used "192.168.86.33.56907 45.33.7.16.443". Hold on a minute.)
These are four tcp sockets that using a tcp socket in http (port 80) to send test results back and forth however the . As soon as the sockets are empty, they'll be marked as some other way than "ESTABLISHED", usually eliminated. Four sockets are about the limit in supplying users in the official HTTP limits.
The "192.168.86.33.56906 45.33.7.16.80" is important, because it's how the http vs https are exchanged. The many unique copies between 45.33.7.16.80 is always there. When they're combined with 192.168.86.33.56906 (in this case) to make it all unique.
The "192.168.86.33.56907 45.33.7.16.443" show using the https secure sockets for a longer time. This is used to keep your Firefox, Chrome, Safari, and so on to rapidly attaching to the server is good, and faster, and often used in accordance with http standards. There will be about 5-10 minutes for this to have been eliminated.
These are who the tcp works on one side. We can also see how tcp works on two sides by seeing how they work on the same side. I put together a https://www.mamp.info/en/ if you like; it runs on Apache web sockets at 8888, WordPress that does applications easily, and a MySql database, by default at 8889. These are a bit different because they're running on the same machine, but it shows the same results.
netstat -an TCP Capture
It's using IPv6, but it's typical of IPv4. It's a local machine and the Apache can run on the ports of 8888, 80 or 443. They chose to run on ports 8888. It's an easy development process. By putting the web server on board lets you look at the both the client and server side.
See here:
tcp46 0 0 *.8888 *.* LISTEN
It's the Apache, listening for both the connection in both the IPv4 and IPv6. Other machines are listening at ports 80 and 443. But we're listening here at 8888.
The top level is
tcp6 0 0 ::1.8888 ::1.60347 ESTABLISHED
tcp6 0 0 ::1.60347 ::1.8888 ESTABLISHED
The applications--the connection from your machine to the server and your server back to the your machine. You'll see them drop with certain errors as well.
The server side is getting TIME_WAIT as the server shuts off the protocol. If you're really interested you can read https://en.wikipedia.org/wiki/Transmission_Control_Protocol.
The udp protocol works in a similar way. We usually send DIS in udp format. See https://en.wikipedia.org/wiki/User_Datagram_Protocol.
netstat -an UDP Capture on a local machine
Wireshark is an interesting way to capture nearly every popular protocol, including DIS. It runs on Windows, Apple, and Unix. It's a free download from https://www.wireshark.org/. BTW, wireshark dot com seems to be present as well, not related anywhere to wireshark.org.
The installation is pretty direct from the start. On the Mac, click on the direct buttons, downloaded in a standard way. It will be installed in /Applications/Wireshark.
Wireshark Installation
When started Wireshark is started you will pick which of several channels. You can pick one of several; in my case it's Wi-Fi (en0), several like en1-en4 Ethernet accounts, and loopback (lo0). The WiFi (called from my machine en0) is what is currently active. You can tell by the frequent bumps in the line. I also happened to have loopback running MAMP, which includes a web server, WordPress, and a MySql server. MAMP kept the web server running at 8888, and the MySql at 8889. They can't be heard outside the machine, other than your own Wireshark on your on own machine. That's handy for your own development.
Wireshark Capture of NPS
You can click the blue shark while it's active. I picked the WiFi, and collected a few minutes of data. That's good advice. You can actively choose to gather several hundred GB if you forget about it.
The below includes the nps.edu, at 205.155.65.12, and my own home machine, nominally at 192.168.86.4.
Wireshark Capture of NPS
You can analyze individual protocols as you like, such as http and DIS. In the case of DIS, you can, if they're on the "right" channel, be displayed. DIS is enabled by Wireshark->Analyze->Enabled Protocols. Scroll down to DIS, Distributed Interactive Simulation. It's already active for certain ports.
Wireshark Decoding of DIS
This term seems a little strange, and it is. In the last few years message state updates have started to be sent across web technologies. The state updates are sent across web servers. How does this happen?
In practice, the web servers are using TCP and UDP sockets, and the DoD applications are accessing the sockets via a higher level API. In effect this is an example of using a higher level API to access the same lower level TCP and UDP APIs. You can think of it as a supporting library, but with the added benefit of also being an officially approved international standard.
There are in practice of lot of other APIs for accessing TCP and UDP socket creation, message transmission, message receipt, and more. There are dozens of C++ libraries. The same is true for many other languages, such as Java and JavaScript. In practice they may hide the direct APIs presented by the operating system or TCP/IP. The libraries may occur at multiple levels of complexity, and hide the sockets discussed above at multiple levels. They may occur at someone low levels. Others may be at much higher levels, such as game engines.
Still, the issue is often recognizing the inherent issues among TCP. UDP, Broadcast, and Multicast sockets, not the specific programming API. Understanding the advantages and limitations of each type of underlying socket is important.
Some example code that demonstates actual use of sockets is provided here. This can be inherently programming language-specific–C++ code, which is not the same as Java code, which is not the same as Javascript code. The problem is that each language will have it’s own project code, and its own source code control site or download site. The DIS Tutorial you are reading is also maintained as a git repository, and it’s impractical to keep all the discussed data as well as all the example code in one repository–the download size alone would be impractical. In addition it wold be difficult to let multiple users add content to multiple sections.
Instead the tutorial maintains links to supporting source project repositories. For example, there may be dozens of example repositories for Java source code examples in projects that show use of sockets, DIS updates, or dead reckoning. There can be matching implementations in C++ or C# in different repositories.
That’s how the code that shows examples of how networking is used are presented here. Sections that have links to example implementations for specific languages are below.
The first example is an example of using TCP sockets as simply as possible. In this case you can think of this as simply showing, as simply as is possible, how to write TCP socket traffic in Java. The development environment is NetBeans, which you can download for free. Two applications are written. A server accepts connections from clients, and then reads back and prints the message sent by the server.
This example would have all the positives and limitations of TCP sockets. A message is being sent from one host to another host. The messages are reliable, but that means if any message is accidentally dropped by the networking system, then a wait period must expire and the TCP network will resend it.
Start the server application first, then run the client application. The client will print the text (unrelated to DIS, btw) at the client. As said, it only demonstrates the sending of a text message. DIS sent over UDP is more difficult without a library to help you.
The example is kept at a separate web site to keep the downloading of the entire wiki somewhat reasonable.
CPP Networking Source Code Examples once an example is deployed
This is a Javascript example from the DISWebGateway project. Download the source code of the application to see the details.
The example here is also using TCP sockets. This is a hangover of Javascript conventions a little while back, but using TCP sockets is no longer strictly required. See "WebRTC" for details.
What DISWebGateway does is operate as both a HTTP web server and reader of UDP sockets on the native Ethernet network. This is complex for new-comers too programmers not familiar with the ideas, but what is happening is that the DISWebGateway can read DIS packets from UDP and pass them on to the web server. The web server can then forward messages to web pages over TCP sockets. In the web page the message is handled by Javascript.
For details, see HTML pages in the directory named "content." Included in some of the pages is a Javascript implementation of DIS.
This is from the googleStreetMap.html web file. There is a similar file that works for OpenStreetMap, a provider of map data that does not charge.
First of all, setting up a location to find another end to the TCP server. We want to hook up to a TCP partner. If we send a message there, the server will send the same message to any other participants, including UDP on the native network.
var WEBSOCKET_URL="ws://localhost:8282";
var websocket;
Javascript is odd in that it cannot wait for every function to be called. Instead, the original object has methods called whenever the Javascript object, such as a WebSocket, is later prepared to handle the call. These methods handle such operations as becoming available to be written too once the socket write operational.
// Set the format we want to use to receive binary messages
websocket.binaryType = 'arraybuffer';
// Attach functions to the the web socket for various events
websocket.onopen = function(evt){console.log("Opened websocket");};//console.log("websocket onopen");};
websocket.onclose = function(evt){console.log("websocket close", evt);};
websocket.onerror = function(evt){console.log("websocket error", evt.data);};
One of the important actions is acting on operations when we receive them from the WebSocket. That's an example of this function, which is called whenever a message arrives:
/** Handle the messages sent from the server to us here. We receive binary
* DIS from the server over the web socket.
* @param {event} evt The receive event object. Contains the binary data to decode
*/
websocket.onmessage = function(evt)
{
// Factory object for creating new PDUs from binary data
var pduFactory = new dis.PduFactory();
// InputStream is modeled on a Java input stream. Pass it binary data,
// and we will read through it, while input stream maintains a current
// place marker
var disMessage = pduFactory.createPdu(evt.data);
// You can trap the various types of PDU here, and
// probably call a specific function to handle each
// type of message. For now we return on everything but
// espdus.
if(disMessage.pduType != 1)
return;
// Retrieve the entity ID from the DIS message, convert it to a JSON
// string, and then use that as a sleazy key into a "hash table" consisting
// of object attributes.
var entityID = disMessage.entityID;
var eidString = JSON.stringify(entityID);
// Convert from DIS global coordinates to latitude/longtitude
var latLonAlt = conversion.convertDisToLatLongInDegrees(disMessage.entityLocation);
// We have an attribute on this object named the JSON text string, with a
// value of the marker data. Look that up.
var theMarker = allEntities[eidString];
// If it's not found, that means it's the first time we've heard of it. Create
// a new one.
if(theMarker === undefined)
{
theMarker = {};
var entityMarking = disMessage.marking.getMarking();
}
Deleted from the code above is mainly how to deal with Google Street Maps. The coding seems strange to non-Javascript code, but is quite apparent. Javascript operates as a single-threaded web page, and to Java or C++ programmers appears to be different.
This section has described some of the capabilities and problems inherent in TCP and UDP sockets, and the nature of Broadcast and Multicast approaches. Broadcast and Multicast are very useful in the DIS world. But at the same time no code of actual implementations was presented. The basic problem is that the code is language-specific. C++ code does not appear the same way that Java or Python or Javascript does. While this section can describe the general behavior, it does not provide specific code.
But that sort of provision is useful, and seeing actual networking programs can save a lot of time. It can also take up unreasonable amounts of disk space for users that are not immediately interested in source code, even if they eventually are. This gets even worse when you think of example projects for several languages that are inherent to an overall tutorial that is not limited to a single language.
Instead, the section provides a section of links to additional source code control sites. For example, a Java project using Multicast, or a Javascript project that uses web technology, or a C++ example. The repositories linked to are not directly part of this project, but can be downloaded. Read on to find links to networking implementations.
This contains links to any source code examples for networking done in Java. Each example typically contains a link to a .md file with an explanation of what the example shows, and a link to a source code control system for the example. This lets users download detailed, well-documented, but potentially large projects for each language the reader is interested in.
This is an example of using Java at a lower API level to send and receive binary data. The example code presented here uses NetBeans, a free development system available at http://netbeans.org. The development process also uses Maven and Ant to build large files.
https://github.com/open-dis/open-dis-java is a DIS networking program that can be run.
An "ant ./runSender.sh" to sends PDUs. A program "ant runReceiver.sh" runs senders and receivers.
The objective was to demonstrate the use of multicast sockets to transmit data, not specifically DIS. Adding DIS was thought to increase the source code used and obscure the use of sockets. Instead, only 355 lines of source are used, which makes the code purpose more understandable.
A single run of the application has two threads active: one thread sends data every few seconds, and the other thread reads from the multicast socket. The sending thread writes to the socket on multicast address “239.1.2.3” and the receiver reads any messages sent to that address.
If the same application is run on two different hosts each will receive the messages of the other. Running on a single host the host will receive all the messages sent by that host.
The multicast socket can subscribe to more than one multicast address. As it stands now, it will not read messages sent to the destination address “239.1.2.100”. It could if the multicast socket performed a “joinGroup” for that IP address.
This contains links to any source code examples for networking done in CPP. Each example typically contains a link to a .md file with an explanation of what the example shows, and a link to a source code control system for the example. This lets users download detailed, well-documented, but potentially large projects for each language the reader is interested in.