Packet, Transaction, or Protocol Programming V1.7

1.     The main difference between traditional and packet/protocol programming

The protocol programming language like PLEX-C doesn’t offer function calls. A program module/block sends a SIGNAL with data to another block explicitly or all blocks that waits for this particular SIGNAL with expected data.

SIGNAL with data is like a PROCEDURE in traditional programming languages such as JAVA, C++. However the signal, when sent, is logged in the CPU processing queues and waited to be dispatched to destination blocks. Thus there is no looping at a block to wait for an expected function/procedure calls with data.

For example, at an Internet PORT’s interface, where a packet comes; we could dispatch the packet to correct programs by sending a SIGNAL with data; in order to do this, an application must register a SIGNAL at the interface, thus the module would dispatch the packet automatically to its destination as long as the conditions met. This SIGNAL could wake up an application in the form such as a process. Currently a program must be looping at a PORT indefinitely to catch a packet, i.e. using a lot of processing power of a PC.

2.     Sample of a packet analyzer and filter

Diagram 1. Examining incoming packets before delivering to a destination program

In the diagram above, all incoming packets would be dispatched to a relevant subsystem for processing in order to determine if the packet is legitimate. If the packet was harmful, it would be logged in database as well as triggering a report to attendance to take appropriate actions.

Basically the Packet Filter Manager would examine types of an incoming packet, and it sends a SIGNAL with relevant data to correct subsystem for validation. The same packet would also be sent to Unpacker module/block for unpacking in the form of a SIGNAL.

Of course programmer could implement

-         Dispatching Interface block to make their subsystem well defined and declared to other subsystem using OOD or API concepts.

-         Library with clear Dispatching Interface to share common functions.

The unpacker’s functionality should be a common task used by many of the subsystems in the diagram. Thus it could use a common library function.

3.     Dispatching interface for protocol programming languages

The entry would be a signal receiving interface with specified/required signal data, where the request would be dispatched to a specific block or module within its sub-system. However the returning data or result would be done by another signal or returning function via the same interface. How data would be communicated, users must refer to the protocol specification. Of course, the interface would also be documented with the meaning of each data in a signal. Developers may attempt to specify the possible returning signal(s) as there may be many possible outcomes for a request. Protocol specification would be a better option.

If an interface module is large, developer could introduce another interface module to access its sub-system.

The interface module should be updated to add more entries or returning signals for other sub-systems. However modifying an existing entry or returning signals to incorporate more data/results would require regression testing or updating of all existing functionality, i.e. lots of work and time as well as potential bugs.

This interface module could be used to be an interface to common functions. This is similar to building a library of functionality.

For PLEX-C, developers could add more new signal data at the end of a signal to carry new information; however modifying an existing signal data would require more investigation to exiting functionality or programming codes. The corresponding protocol specification and dispatching interface’s documentation must be updated for new message data.

4.     Sample program to receive an incoming packet

Assuming that the unpacker had removed all irrelevant headers of a packet before delivering to a program, the company XYZ had registered an expected SIGNAL at Registration Interface Manager as XYZReportingTask.

In a dormant process module, it could be programmed as (samples to demonstrate the structure or format of receiving and sending SIGNALs)

-------------------------------

RECEIVE XYZReportingTask OriginatingAddress,

                                                        NumberOfReport,

                                                        NameOfReport,

                                                        FieldData1,

                                                        FieldData2,

                                                        Etc;

GOTO ProcessingReport; ! redirect signal processing to a label called
                                                     ! ProcessingReport

                                                     ! by using label, programmers could place all expected

                                                     ! receiving SIGNALS and data at one place in a block. Just

                                                     ! for organizing and ease in debugging and reviewing a
                                                     ! programming block

ProcessingReport:    ! this is the label in this block to process data coming
                                       ! from the signal XYZReportingTask

-         Processing the report data or further unpacking in forms recognized by XYZ system.

-         Log data in database as needed

IF all data were as expected and acceptable

SEND TO PrinterBlock StartPrintingReport CompanyName, Address, PhoneNumber, InvoiceID, etc;

      ELSE  

SEND SpecialAnalyzer CompanyName, Address, PhoneNumber, InvoiceID, ErrorCode, etc;

      ENDIF;

EXIT;  ! Release the central processor for other processing tasks

-------------------------------

The XYZReportingTask, StartPrintingReport, and SpecialAnalyzer are SIGNAL names. All variables followed those SIGNALs are signal data. The program would process signal data with programming statements similar to any traditional programming languages including INSERT those in database.

The XYZReportingTask signal came from the central processor queue, which was originally inserted in by the Delivery Manager block. This program didn’t loop for an incoming message at an Internet PORT. The Delivery Manager must include the destination Block Name, Signal Name as well as signal data to this programming block.

This programing block sends the signal StartPrintingReport to the central processor queue, which would be delivering to the programming block PrinterBlock for printing a good report.

This programing block sends the signal SpecialAnalyzer to any programming block that expects this signal with data for analyzing errors.

All internal/block SIGNALS had been registered in the registration system at compilation, thus the central processor knows where or the block should receive a particular signal correctly.

5.     Central Processor

Basically the central processor has signal queues with associated data. The queue is FIFO rule. There are several priority queues to process data according to level of importance, e.g. system may insert their signals in Priority Queue A. Queue Priority B is for normal tasks. Priority Queue C is for lower level tasks such as printing.

The queued SIGNALs would be delivered to a particular programming block or be broadcast to many blocks waiting for the same signal with data.

There must be syntax for a packet/protocol programming language to specify a method to send or receive a SIGNAL.

6.     Tracing/debugging issues on live system and patching

Ericsson’s APZ (central processor) offers a packet programming language called PLEX-C. This language also uses a specific syntax for SIGNALs sending and receiving. I used to work over there, but I didn’t remember the syntax.

The system offered a tool called TEST SYSTEM. Testers could activate this tool to see signal names and signal data passing between programming blocks. By analyzing passing data in a signal, testers could determine if a block analyzed and passed data correctly or not.

By checking signal data at some particular points, testers could narrow down issues quickly and figure out a solution by writing assembly patches/codes to load on a live switch. Other testers could use these patches as a temporary solution to continue their testing activity. The permanent solution would be implemented by high level programming language such as PLEX-C, compiled into assembly codes, and then loaded on the central processor (APZ) later.

Usually the process to implement a solution in high level language would take more time and scheduled at a determined phase. Thus temporary patches were useful to keep testing activity going.

7.     Parallel processors

The Ericsson’s APZ has 2 main processors, which has many CPU in each processor. One of them is the executive processor and the other is standby processor.

The executive processor is the live node to handle real time data and processing. Data is also passed to the standby processor as a mirror database and backup. If the executive processor is faulty for a reason, the standby processor would take over as the executive processor.

In normal circumstances, new programming codes would be compiled into assembly languages and loaded on the standby processor. Technical support would trigger a process to transfer real-time data on the executive processor to new codes and database on the standby processor before an automatic switching processors happened, i.e. standby processor with new codes becomes a live node.

-         The old codes and database were still on the standby side. If the executive side was faulty for a reason, technical support would switch the standby side with previous codes back to executive side as a live node.

-         Both processors would be brought back to run in parallel later if everything was normal.

APZ is used in telecom switches, which couldn’t be down for more than 20 minutes (decade ago allowed time) a year. Thus the process to switch processors over was short and carried out in maintenance windows, e.g. 12AM to 5AM.

8.     Sample of tracing or verifying the SMTP subsystem in the diagram above

Tester could initiate TRACE of

-         Incoming signals to the Packet Filter Manager, i.e. incoming packets

-         Incoming signals to the interface block of SMTP Subsystem, i.e. delivered packets from the Packet Filter Manager

The SMTP Subsystem could log some data into database by a programming block, e.g. by block UpdateData.

-         Trace a variable in the block UpdateData, e.g. External_OPC variable, that would change value before committing data into database

-         Outgoing signals from the block UpdateData

-         Outgoing signals from the interface block of SMTP Subsystem, i.e. packets out from the SMTP Subsystem

-         Incoming signals to the interface block of Report Manager

-         Trace a variable in a block of Report Manager, e.g. ErrorCode, that would change value before committing data into database

-         Outgoing signals from the interface block of Delivery Manager

Use another PC connecting to this system using an Ethernet cable or WiFi in order to send packets.

There should be a tool for testers to assemble a file of packets in a proper protocol format. Testers could create many packets with different scenarios. Send a good/bad packet or a set of packets in a file with different errors.

Based on the packet sent and signal data collected in the above traces, testers should be able to determine if the overall SMTP Subsystem have been functioned correctly.

-         There should be signal descriptions associated with the system to interpret the meaning of each signal data in a signal to/from a block.

-         If the values of the traced variables above were set before or after a signal leaving/coming to a block as expected, this would mean the data had been committed to database at proper time. Verify database to ensure its value and format.

Testers could also initiate a TRACE on the Outgoing Packet Manager in case the PC request the originating node to resend an erroneous packet.

If errors or unexpected behaviors have been detected, testers could trace many blocks in the subsystem to figure out the location of bug(s). Of course, assembly patches could be implemented to load on the node to correct issues.

9.  Notes about trace tools Ericsson’s APZ or APY and a packet analyzer

-         Notes were written at https://peterboroughtechservices.blogspot.ca/p/signalstracing-on-apz-ericssonsapz-is.html

-         Couple with special commands, APY could be used to implement the packet analyzer above to track down illegitimate activity, to record, and to bring those nodes down. Notes at https://peterboroughtechservices.blogspot.ca/p/tracking-adevice-using-internet-a.html

The detailed syntax must be provided by the equipment provider.

10.     Packet Analyzer

I had developed the concept of packet analyzer or special firewall earlier. Notes could be found at https://peterboroughtechservices.blogspot.ca/p/my-special-firewall.html. There is a link in the notes to download my documents.

The packet analyzer could be implemented to protect a PC or network. It is a little bit different than the current antivirus programs in the market.  The concept was based on analyzing incoming and outgoing packets as well as the protocol specification for each Internet protocol and current activity within a PC or networks.

I like the unattended mode in my document as hackers had threatened to enter my PC when I was away from my PC, which was connected to the Internet while I walked away.

-         Basically the Packet Analyzer would detect if a PC or network had no user activity such as typing on a keyboard.

-         Current activity such as downloading files using http or ftp

-         If there was no activity or PC’s screen saver was activated, the Packet Analyzer could shutdown Internet connection, but allowing current [pre-defined] activity to continue until completed. After completion, the Internet was completely off. Some activity wouldn’t be allowed while users were away from their terminal, btw, as a pre-defined rule.

-         If user unlocked the screen again, the Packet Analyzer would restore Internet connection.

Personally I don’t want any software applications that I am using access or open a Port of the Internet communication, e.g.

-         Microsoft Office or Adobe’s PDF unless it is opened on a web browser. End users didn’t buy an Internet or server version of MS Word, thus all edits should be local.

-         Updates could be done periodically, but shouldn’t have a permanent connection to an Internet port. Perhaps at installation, user would accept the update feature, thus an Internet defender, e.g. Packet Analyzer, would let it open port sometimes for checking and downloading. Start of downloading updates should ask for user’s permission. We don’t want hackers faking a company to upload harmful software to our PC.

-         Having a Port open permanently would give hackers an opportunity to enter our PC.

-         Internet games, Internet applications, and Internet streaming applications are within another category.

Recently hackers had faked downloads from well-known companies to a user’s PC. The actually downloads contained harmful virus or Trojan Horses.

The Packet Analyzer concept is simple, but software product providers must analyze a protocol and legitimate activity in order to provide a best Internet defender. Antivirus companies could use this concept as well as their existing features such as detecting known hacking programs to enhance a PC security.

Law enforcement would be able to develop all features of a packet analyzer including special measures such as tracking and bringing down attackers.

Private packet analyzer for users would focus on the features to defend user’s PC or networks. It could log intruder’s data and reported to local authority later. Unless the private companies had permissions by law enforcement, they shouldn’t attempt to launch special measures against intruders as this may involve special rules and agreement among local law enforcement and many countries.

11.     Features should be included in a personal PC’s Internet Defender

The Internet Defender or Packet Analyzer should offer an interface for users to do the following simple things:

-         Block all Internet ports

-         Open http port

-         Start a program within the PC – of course an application that allows accessing Internet using http, e.g. a web based game or a web based chat room.

-         If the application worked fine. Only http port is needed.

-         If it didn’t work? The Internet Defender should know which port an external application is trying to open or communicate, i.e. check to see if the target server relayed answers or response to another port of this PC.

-         Internet Defender would prompt the user to open that port manually, if a request or outgoing TCP/IP packet had been detected earlier.

If the Internet Defender could also offer blocking an (troublesome) Internet protocol, it would be easier, too. In this case, users would block some protocols regardless of ports. If a user allowed a protocol regardless of ports, it may open many gates for intruders.

Note that some applications must be originated in a PC in order to get response from an external source, i.e. responses or messages came to a PC without a PC’s originating request would be illegitimated.

In contrast, some process could be started by an outsider such as incoming email or use of incoming SMTP.

12.     System Security

The Internet Defender or Packet Analyzer are screening and validating Internet messages at packet layer coupled with current activity in a PC or network. Thus the system is quite secure.

The only concern would be lower layers of an OS such as transmission layer. Those lower layers should only be accepting electrical signals to pack those into TCP/IP or UDP packets for processing OR unpacking a TCP/IP or UDP messages into electrical signals for transmission. No funny or hidden functionality should be implemented.

13. Register Interface Manager

The signal XYZReportingTask with data D1, D2, D3, …, D_n described in section 4 and diagram 1 will be delivered to its dormant process upon receiving by system thorough Internet communications. With this implementation, developers could avoid creating a forever loop to catch Internet data at an Internet port. The dormant process would be wakened up to handle data as needed, i.e. avoid wasting CPU processing power and RAM.

There would be several ways to implement and enforce dormant process to save processing power of a system, e.g.

·        For time slot applications such as collecting data in a predefined interval, e.g. 12 pm-1 pm, the processing application would be wakened up by an Internet signal via Register Interface Manager. It processes data between the allocated interval, and complete required tasks received until 1 pm. After processing the last signal, it would be back in sleep mode as coded by application developers.

·        Intermittent Internet process, i.e. processing Internet messages randomly, the application would be wakened up and processed data via a signal from Register Interface Manager. After processing data, it would be back to sleep mode, if idle for a couple of minutes as coded by application developers.

·        OS could determine any applications in idle mode for a predefined time interval; it will put those applications or processes in sleep mode.

Those suggested methods would help performance of a computer system.