MDC Protocol Selection & System Tuning

 

If your implementation of the MDC is via RF Modem (COMTYPE=1) much of the information discussed in this section will not apply.  However, if your implementation will be using a commercial carrier or private IP based network then you have a choice of using TCP (Transport Control Protocol) or UDP (User Datagram Protocol).  Choosing between TCP and UDP will depend on the specifics of your communications environment.  Sometimes the only way to know for sure which protocol will work best is to test it. Having said that, the following information and discussion will help you understand some basic elements of each communication protocol, identifying the pros and cons of each and how to tune Crimestar MDC software accordingly.

PACKET BASICS: Almost all data messages that are sent over an IP based communications transport are generally broken down by the protocol into a series of smaller chunks referred to as “packets”.  Then each of these data packets are sent to their respective destination where they are reassembled into the original message.  The size of these packets is managed by the configuration of the IP communications layer.  The smaller the defined packet size, the more packets that are needed to deliver the same volume of data.  If the IP packets are too small, lots and lots of packets are required to deliver the data and all those extra packets need to be reassembled in the proper order to recreate the original data.  If however, the packet sizes are too big, then there is a higher the likelihood or probability that a packet will get damaged or become corrupted during transport which will require the re-transmission of that packet.  The optimum packet size depends on your network.  Understanding the basics of this packet style of communication is important to understanding a few of the distinctions between the TCP and UDP protocols.   The MDC software itself uses packets to break larger messages into smaller chunks (even when implemented via RF Modem COMTYPE=1) but don’t confuse MDC message packets with IP data packets as they exist at different layers of the communications path and are not the same thing.  For example the MDC software may take a large 2000 byte message and divide it into 4 different 500 byte MDC message packets.  The actual size of an MDC message packet is controlled by the MAXPACKETSIZE entry in the Crimestar INI file.  The MDC software implements a packet acknowledgement protocol where each MDC message packet sent must be ACK’d by the receiving MDC.  An MDC message packet that is not Ack’d is presumed to have not been delivered and is resent.  The maximum number of time the MDC software will reattempt to send a message packet is controlled by the MAXRETRYCOUNT entry in the Crimestar INI file.  So if for example; suppose the defined IP packet size is 250 bytes and the defined MDC maximum packet size is 500 bytes.  When the MDC software needs to deliver that 2000 byte message, it divides it into the 4 different 500 byte packets and, each of those MDC message packets are sent via the IP communication layer (using whichever protocol has been selected).  The IP communications layer sees each MDC packet as a message and divides it into 250 byte data packets and attempts to deliver those packets to the destination address.  As the IP communication layer receives the packets it assembles them and delivers them to the MDC software. The MDC software then analyzes the received MDC packet to verify its integrity and replies with an ACK to let the sender know that it can now send the next MDC packet.  Once all MDC packets are received by the MDC software the packets are reassembled into the original message. So as you can see for this discussion there are two layers of packets that exist.  There are the MDC message packets which represent smaller chunks of the original message and there are IP packets which would be smaller chunks of an MDC message packet.   If the defined MAXPACKETSIZE used by the MDC is either the same as or small than the packet size utilized by the IP transport layer then there is a 1-to-1relationship between MDC message packets and IP packets where each MDC message packet only requires 1 IP packet.

TCP: The TCP protocol (COMTYPE=2) is a connection based protocol.  This means that the MDC client in the car will search for the host MDC controller using the controller’s IP address defined in the Crimestar INI file and establish a “connection” (data pipeline) with that host.  The TCP connection based protocol generally provides a more reliable form of message/data delivery between two points because of this established connection.   Rarely are the sending machine and destination machine on the same subnet (common group of network addresses), especially when using GPRS via a commercial carrier. Usually the two machines must communicate with each other by having their data packets relayed from point-to-point/machine-to-machine until the packet arrives at its destination.  This persistent connection that is inherent to TCP helps route packets through gateway machines, routers and the maze of systems that must be traversed to get data from one point to another.  TCP guarantees that data packets will get through the maze and be delivered in sequential order making their reassembly much easier.

While TCP can provide reliable data delivery, it can only do so when a connection between the client and host exists.  The challenge presented by the MDC environment is that the client (i.e. the computer in the car) is moving around and relies not on wires but rather radio signals to stay connected.  Much like what you might experience from time to time when using a cell phone, the GPRS service provided by commercial carriers can have ”dead-spots” where the radio signal is weak or blocked completely. When that happens, the TCP connection can and often is broken. When the data connection breaks between a client and the host the MDC system cannot communicate.

In an attempt to account for this condition, the MDC client software attempts to detect connection disconnects and will automatically try to re-establish a connection with the host controller.  Please realize that attempts to re-connect can only be done by the client software in the car, because the IP address of the host MDC controller is located at a fixed known static IP address.  Therefore the client know the address to go to try to connect with the host controller but the host controller does not necessarily know  the IP address of the client so the host cannot effectively and reliably re-initiate a connection.

When these connection breaks occur it presents an additional burden on the MDC controller.  As each connection to the host controller consumes a certain number of system resources.  When a client establishes a connection, the host controller allocates system resources to manage that connection.   If the connection experiences a hard-break; (meaning that the break occurred as a result of something other than a disconnect sequence issued by the client machine) the controller does necessarily know that the connection is broken and holds those system resources.  In the mean time the client re-attempts to establish a new connection with the host.  This new connection in turn consumes some system resources.  As this connect/disconnect dynamic repeats the host controller can slowly consume more and more of the memory resources on the computer until it communication is interrupted.  To combat this condition the MDC controller must monitor internal connections and try to determine though inactivity which connections are no longer being used and automatically disconnect them in order to free up the system resources consumed by the broken connection.   This connection housekeeping process requires extra work for the host controller on an ongoing basis.

So while the connection that is inherent to using TCP provides for a better and more reliable data transfer, this benefit is offset by the fact that vehicles in motion often experience radio signal interruptions that subsequently break the TCP connection; requiring the MDC software to detect and attempt to automatically repair or re-establish a connection with the host.

UDP: The UDP protocol (: COMTYPE=3) is a connectionless protocol.  As such data packets do not have a connection path or pipeline that they can follow. Each packet transmitted must find its own way to its destination.  This means that, depending upon the network, different packets can take different paths to get to the destination IP address and some data packets may be delayed and subsequently not delivered in the order that they were transmitted.  While this can be a problem it is easy to manage through proper configuration.  By ensuring that the MDC maxpacket size is less than the IP packet size used for UDP, each packet must reach its destination and be acknowledged before the next packet is sent. .

The advantage to UDP is that since it does not use a connection, there is no connection for the controller to keep track of and no need to monitor for timeout or broken connections.  Likewise, there is no need to re-establish connections if/when they break which can speed up the process of communication recovery after having lost radio communication. However, since UDP delivery requires the controller knowing the IP address of the client, UDC is best suited for situations where the MDC client in the car uses a static or fixed IP address.

General System Performance:  Depending upon your activity level and the number of MDC field units deployed the MDC Controller may sit idle much of the time.  However, when it does need to process transactions it must be able to do so very very quickly.  As such the machine functioning and the MDC controller should:

1.) Be a dedicated machine where the only application that the computer is responsible for running is the MDC controller.  (Running the MDC Controller on your “Server” or other shared computer that may, at times be busy with other processing will likely cause an increased error rate in handling communications with MDC workstations.)

2.) Have a very fast CPU processor (Intel i3 or faster) with ample memory.

3.) Have a high speed and stable connection to the Crimestar database.

* BE VERY CAUTIOUS OF WINDOWS TIMEOUT OR SLEEP SETTINGS.  THE MDC COMMUNICATIONS APPLICATION IS RELIANT UPON THE COMPUTER COMMUNICATIONS BEING AVAILABLE 100% OF THE TIME.  MS WINDOWS POWER MANAGEMENT, SLEEP OR TIMEOUT SETTINGS CAN PUT THE COMPUTER INTO A LOW POWER OR SLEEP MODE WHICH WILL DISRUPT NETWORK COMMUNICATIONS AND CAUSE YOUR SYSTEM TO APPEAR "FROZEN".  MICROSOFT AUTOMATIC UPDATES CAN AND OFTEN WILL CHANGE THESE SETTINGS ON YOUR COMPUTER WITHOUT YOUR KNOWLEDGE.  AS A RESULT MANY IT PROFESSIONALS TUN OFF THE WINDOWS AUTOMATIC UPDATES ON THEIR SERVER MACHINES AND HANDLE ALL UPDATES MANUALLY.