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.
No comments:
Post a Comment