Using TCP/IP protocol for Internet applications

Using TCP/IP protocol for Internet applications or IoT
---------------------------------------------------------------------
Protocol applications are easier to understand and trouble shoot as long as you had the protocol specification. One of the best protocol specifications that I had read was ANSI-41 rev B protocol standard used in TDMA cellular telephony.

Basically the protocol specification described incoming message/packet with details of data, e.g. meaning of the first octet, second octet, etc. The protocol specification also describes the interaction between sub systems. For example, the expected returned message/packet for a message/packet request. They called those Invoke Request and Return Result in ANSI-41 protocol. I like to work with protocol as it simplify things and easy to learn quickly.

If you're using TCP/IP, all you need is to pack your data in a message followed specific/your protocol, and then send the message over the Internet to its destination. The receiver would open/unpack the message and interpret data based on the its protocol. The destination node performed the required task, and then would send back a message with required result.
- For example, in the Invoke Message Octet #1 is the ID of the Invoke Message, Octet #2 is scale indicator if = 1 is Kg, if =2 is lb, if=0 reading in octet #3 and #4 are unreliable; the octet #3 is weight number; the octet #4 is decimal places. Thus the destination would know the scale. The Return Message would perform required operation and send back Return Message including the Invoke Message ID + octets with data.
- Usually we don't shrink the message's length even if one of octet data within the message was unreliable. You only need to find a way to flag the receiver about that octet. For example, use an indicator or maximized the octet value.
- The return message would contain the ID of the Invoke message in order to trigger the right thread or calling party.
- A TCP/IP message comes as a string of octets to a destination node. Thus you would need to specify a message type or ID and length of the message in a TCP/IP request in one of those octets. It's likely that the first octet identifies the message type or ID; the second octet would specify the length of the message.
- This is asynchronous communication, i.e. you send your request and hand-off. The return message would trigger your system to response. This is not sending a message and hang-on there to wait for a response. If you didn't use asynchronous message/programming, you would seize the computer's [tablet or smartphone] processing power until getting a reply.
- If you used the XML file to contain your request/reply, the message could be longer or more bytes. For example, developers must include opening/closing of a tag name, symbols, and data.
- Btw, this asynchronous communication work well with Ericsson AXE or switch. The APZ or central processors of an AXE support PLEX-C, which is a protocol like programming language. PLEX-C doesn't look like C programming language at all.

You should read the ANSI-41 rev B standard; you would get a better understanding of a protocol. This protocol spec was written by many top engineers from many telecommunication organizations.

* Why reading ANSI-41 rev B standard, not the latest ANSI-41 standard? The goal is to learn how to write a protocol specification. Latest ANSI-41 [thicker] includes more features of cellular telephony, but you're not learning telecom. Read the last section, if I recalled correctly, would describe the octets and its meanings. The earlier sections described how many sub systems are communicating with each other to perform a task using diagrams.
-------------------

2016-01-15

It seems to me that C#, VB. NET, and c programming languages don't support packet based applications mentioned above, i.e. Microsoft didn't support this type of programming.

The receiver has to "loop" forever to catch the incoming packet. This means a lot of processing power dedicated to lopping.

I am wondering how the receiver could catch the beginning of a packet or entire packet, i.e. not the middle of a packet. It's a mystery.

* PLEX-C and Ericsson's APZ supports the packet type programming.