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
2. Sample of a packet analyzer and filter
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
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 packetFor 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.
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
! 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
! 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
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
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
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
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.
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.
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.
Law
enforcement would be able to develop all features of a packet analyzer
including special measures such as tracking and bringing down attackers.
-
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.
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
13. Register Interface Manager
The signal XYZReportingTask with data D1, D2, D3, …, Dn 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.
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, …, Dn 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.
