Implementation of TCP/IP using pSOS
Document By
SANTOSH BHARADWAJ REDDY
Email: help@matlabcodes.com
Engineeringpapers.blogspot.com
More Papers and Presentations available on above site
Abstract - TCP/IP Support - pSOSystem’s
TCP/IP networking capabilities are
constructed around the pNA+ software
component. pNA+ includes TCP,UDP,IP,
accessed through the industry standard
socket programming interface. pNA+ offers
services to application developers as well as
to other pSOSytem networking options such
as RPC,NFS,FTP and so forth. UDP
provides a datagram mode of packet-
switched communication. It allows users to
send messages with a minimum of protocol
overhead. However, ordered, reliable
delivery of data is not guaranteed. The IP
layer is used for transmitting blocks of data
called datagrams. This layer provides
packet routing, fragmentation and
reassembly of long datagram through a
network or internet. Multicast IP support is
implemented in the IP layer. The Network
Interface(NI) layer isolates the IP layer
from the physical characteristic of the
underlying network medium. It is hardware
dependent and is responsible transporting
packets within a single network. Because it
is hardware dependent, the network
interface is not part of pNA+ proper.
Rather, it is provided by the user, or by ISI
as a separate piece of software.
I. INTRODUCTION
TCP/IP
Transmission Control Protocol/Internet
Protocol (TCP/IP) is not a single protocol; it
refers to a family or suite of protocols. The
suite consists of a four-layer model.
Network Interface Layer - The Network
Interface Layer is equivalent to the
combination of the Physical and Data Link
Layers in the OSI model. It is responsible for
formatting packets and placing them onto the
underlying network. All common Data Link
protocols support TCP/IP.
Internet Layer - The Internet Layer is
equivalent to the Network Layer in the OSI
model. It is responsible for network
addressing. The main protocols at this layer
are: Internet Protocol (IP), Address
Resolution Protocol (ARP), Reverse Address
Resolution Protocol (RARP), Internet Control
Message Protocol (ICMP), and Internet Group
Management Protocol (IGMP).
The Transport Layer - The Transport Layer is
equivalent to the Transport Layer in the OSI
model. The Internet Transport layer is
implemented by TCP and the User Datagram
Protocol (UDP). TCP provides reliable data
transport, while UDP provides unreliable data
transport.
The Application Layer - The Application
Layer is equivalent to the top three layers,
(Application, Presentation and Session
Layers), in the OSI model. The Application
Layer is responsible for interfacing between
user applications and the Transport Layer.
Applications commonly used are File Transfer
Protocol (FTP), Telnet, Simple Network
Management Protocol (SNMP), Domain Name
system (DNS), Simple Mail Transfer Protocol
(SMTP), and so on.
pSOS
pSOSystem is a modular, high-performance
real-time operating system designed
specifically for microprocessors. It provides a
complete multitasking environment based on
open systems standards. pSOSystem is
designed to meet three overriding objectives
(i)Performance, (ii)Reliability,(iii)Ease-of-
Use. The result is a fast, deterministic, yet
accessible system software solution.
Accessible in this case translates to a minimal
learning curve. pSOSystem is designed for
quick startup on both custom and commercial
hardware. The pSOSystem software is
supported by an integrated set of cross
development tools that can reside on UNIX- or
DOS-based computers. These tools can
communicate with a target over a serial or
TCP/IP network connection.
System Architecture
The pSOSystem software employs a modular
architecture. It is built around the pSOS+ real-
time multi-tasking kernel and a collection of
companion software components. Software
components are standard building blocks
delivered as absolute position-independent
code modules. They are standard parts in the
sense that they are unchanged from one
application to another. This black box
technique eliminates maintenance by the user
and assures reliability, because hundreds of
applications execute the same, identical code.
Unlike most system software, a software
component is not wired down to a piece of
hardware. It makes no assumptions about the
execution/target environment. Each software
component utilizes a user-supplied
configuration table that contains application
and hardware-related parameters to configure
itself at startup. Every component implements
a logical collection of system calls. To the
application developer, system calls appear as
re-entrant C functions callable from an
application. Any combination of components
can be incorporated into a system to match
your real-time design requirements. The
pSOSystem components are listed below.
NOTE: Certain components may not yet be
available on all target processors. Check the
release notes to see which pSOSystem
components are available on your target.
1. pSOS+ Real-time Multitasking Kernel. A
field-proven, multitasking kernel that provides
a responsive, efficient mechanism for
coordinating the activities of your real-time
system. 2.pSOS+m Multiprocessor
Multitasking Kernel. Extends the pSOS+
feature set to operate. Seamlessly across
multiple, tightly-coupled or distributed
processors. 3.pNA+ TCP/IP Network
Manager. A complete TCP/IP implementation
including gateway routing, UDP, ARP, and
ICMP protocols; uses a standard socket
interface that includes stream, datagram, and
raw sockets. 4.pRPC+ Remote Procedure
Call Library. Offers SUN-compatible RPC
and XDR services; allows you to build
distributed applications using the familiar C
procedure paradigm. 5.pHILE+ File System
Manager. Gives efficient access to mass
storage devices, both local and on a network.
Includes support for CD-ROM devices, MS-
DOS compatible floppy disks, and a high-
speed proprietary file system. When used in
conjunction with the pNA+ component and the
pRPC+ subcomponent, offers client-side NFS
services. 6.REPC+ ANSI C Standard
Library. Provides familiar ANSI C run-time
functions such as printf(), scanf(), and so forth,
in the target environment.
pSOS+ Real-Time Kernel
The pSOS+ kernel is a real-time, multitasking
operating system kernel. As such, it acts as a
nucleus of supervisory software that Performs
services on demand Schedules, manages, and
allocates resources Generally coordinates
multiple, asynchronous activities. The pSOS+
kernel maintains a highly simplified view of
application software, irrespective of the
application’s inner complexities. To the
pSOS+ kernel, applications consist of three
classes of program elements (i)Tasks (ii)I/O
Device Drivers (iii)Interrupt (iv)Service
Routines(ISRs).
Multitasking Implementation - A
multitasked system is dynamic because task
switching is driven by temporal events. In a
multitasking system, while tasks are internally
synchronous, different tasks can execute
asynchronously. Figure 2-1 illustrates the
multitasking kernel. A task can be stopped to
allow execution to pass to another task at any
time. In a very general way, Figure 2-1
illustrates multitasking and how it allows
interrupt handlers to directly trigger tasks that
can trigger other tasks.

Figure 1 - pSOS Kernel
Thus, a multitasked implementation closely
parallels the real world, which is mainly
asynchronous and/or cyclical as far as real-
time systems apply. Application software for
multitasking systems is likely to be far more
structured, race-free, maintainable, and re-
usable. Several pSOS+ kernel attributes help
solve the problems inherent in real-time
software development. They include
pSOSystem System Concepts pSOS+ Real-
Time Kernel
pREPC+ ANSI C Library
Most C compilers are delivered with some sort
of run-time library. These run-time libraries
contain a collection of pre-defined functions
that can be called from your application
program. They are linked with the code you
develop when you build your application.
However, when you attempt to use these
libraries in a real-time embedded system, they
encounter one or more of the following
problems (i) It is the user’s responsibility to
integrate library I/O functions into the target
environment, a time-consuming task. (ii)The
library functions are not reentrant and
therefore do not work in a multitasking
environment. (iii) The library functions are not
compatible with a published standard,
resulting in application code that is not
portable.
The pREPC+ ANSI C Library solves all of the
above problems. First, it is designed to work
with the pSOS+ Real-Time Multitasking
Kernel and the pHILE+ file system manager,
so all operating system dependent issues have
been addressed and resolved. Second, it is
designed to operate in a multitasking
environment, and finally, it complies with the
C Standard Library specified by the American
National Standards Institute.
Functions Summary
The pREPC+ library provides more than 115
run-time functions. Following the conventions
used in the ANSI X3J11 standard, these
functions can be separated into 4 categories:
1.Character Handling Functions 2.String
Handling Functions 3.General Utilities
4.Input/Output Functions. The Character
Handling Functions provide facilities for
testing characters (for example, is a character a
digit?) and mapping characters (for example,
convert an ASCII character from lowercase to
uppercase). The String Handling Functions
perform operations on strings. With these
functions you can copy one string to another
string, append one string to another string,
compare two strings, and search a string for a
substring. The General Utilities provide a
variety of miscellaneous functions including
allocating and deallocating memory,
converting strings to numbers, searching and
sorting arrays, and generating random
numbers.
Overview of Networking Facilities in
pSOS
pSOSystem real-time operating system
provides an extensive set of networking
facilities for addressing a wide range of
interoperability and distributed computing
requirements. These facilities include TCP/IP
Support - pSOSystem’s TCP/IP networking
capabilities are constructed around the pNA+
software component. pNA+ includes TCP,
UDP, IP, ICMP, IGMP, and ARP accessed
through the industry standard socket
programming interface. pNA+ offers services
to application developers as well as to other
pSOSystem networking options such as RPC,
NFS, FTP, and so forth. PNA+ also works in
conjunction with pSOSystem cross
development tools to provide a network-based
download and debug environment for single-
or multi-processor target systems.
SNMP — Simple Network Management
Protocol, is a standard used for managing
TCP/IP networks and network devices.
Because of its flexibility and avail-ability,
SNMP has become the most viable way to
manage large, heterogeneous networks
containing commercial or custom devices.
FTP, Telnet, TFTP — pSOSystem
environment includes support for the well
known internet protocols File Transfer
Protocol (FTP) and Telnet (client and server
side), and Trivial File Transfer Protocol
(TFTP). FTP client allows you to transfer files
to and from remote systems. FTP server
allows remote users to read and write files
from and to pHILE+ managed devices. Telnet
client enables you to login to remote systems,
while Telnet server offers login capabilities to
the pSOSystem shell, pSH, from remote
systems. TFTP is used in pSOSystem Boot
ROMs and is normally used to boot an
application from a network device.
RPCs — pSOSystem fully supports Sun
Microsystems’ Remote Procedure Call (RPC)
and external Data Representation (XDR)
specifications via the pRPC+ software
component. The pRPC+ component allows
you to construct distributed applications using
the familiar C procedure call paradigm.
NFS — pSOSystem environment offers both
Network File System (NFS) client and NFS
server support. NFS server allows remote
systems to access files stored on pHILE+
managed devices. NFS client facilities are part
of the pHILE+ component and allow your
application to transparently access files stored
on remote storage devices.
II. pNA+ Software Architecture
The module in pSOS that is used exclusively
for networking is pNA+ module. Thus if a
application requires TCP/IP networking this
pNA+ module is to be added to the pSOS+
kernel. pNA+ is organized into four layers.
The Figure below illustrates the architecture
and how the protocols fit into it.
Figure 2. pNA+ Architecture
The socket layer provides the application
programming interface. This layer provides
services, callable as re-entrant procedures,
which your application uses to access internet
protocols; it conforms to industry standard
socket syntax and semantics. In addition, this
layer contains enhancements specifically for
embedded real-time applications. The
transport layer supports the two Internet
Transport protocols, Transmission Control
Protocol (TCP) and User Datagram Protocol
(UDP). These protocols provide network
independent transport services. They are built
on top of the Internet Protocol (IP). TCP
provides reliable, full-duplex, task-to-task data
stream connections. It is based on the internet
layer, but adds reliability, flow control,
multiplexing, and connections to the
capabilities provided by the lower layers. UDP
provides a datagram mode of packet-switched
communication. It allows users to send
messages with a minimum of protocol
overhead. However, ordered, reliable delivery
of data is not guaranteed. The IP layer is used
for transmitting blocks of data called
datagrams. This layer provides packet routing,
fragmentation and reassembly of long
datagrams through a network or internet.
Multicast IP support is implemented in the IP
layer.
III. ALGORITHM
BORDER GATEWAY PROTOCOL
The Border Gateway Protocol (BGP) is the
core routing protocol of the Internet. It works
by maintaining a table of IP networks or
'prefixes' which designate network reachability
among autonomous systems (AS). It is
described as a path vector protocol. BGP does
not use traditional IGP metrics, but makes
routing decisions based on path, network
policies and/or rulesets. Since 1994, version
four of the protocol has been in use on the
Internet. All previous versions are now
obsolete. The major enhancement in version 4
was support of Classless Inter-Domain
Routing and use of route aggregation to
decrease the size of routing tables. From
January 2006, version 4 is codified in RFC
4271, which went through well over 20 drafts
from the earlier RFC 1771 version 4. The RFC
4271 version corrected a number of errors,
clarified ambiguities, and also brought the
RFC much closer to industry practices. BGP
was created to replace the EGP routing
protocol to allow fully decentralized routing in
order to allow the removal of the NSFNet
Internet backbone network. This allowed the
Internet to become a truly decentralized
system.
Very large private IP networks can also make
use of BGP. An example would be the joining
of a number of large Open Shortest Path First
(OSPF) networks where OSPF by itself would
not scale to size. Another reason to use BGP
would be multihoming a network for better
redundancy either to a multiple access points
of a single ISP (RFC 1998) or to multiple
ISPs. Most Internet users do not use BGP
directly. However, since most Internet service
providers must use BGP to establish routing
between one another (especially if they are
multihomed), it is one of the most important
protocols of the Internet. Compare this with
Signaling System 7 (SS7), which is the inter-
provider core call setup protocol on the PSTN.
BGP operation
BGP neighbors, or peers, are established by
manual configuration between routers to create
a TCP session on port 179. A BGP speaker
will periodically send 19-byte keep-alive
messages to maintain the connection (every 60
seconds by default). Among routing protocols,
BGP is unique in using TCP as its transport
protocol. When BGP is running inside an
autonomous system (AS), it is referred to as
Internal BGP (IBGP Interior Border Gateway
Protocol). When BGP runs between ASs, it is
called External BGP (EBGP Exterior Border
Gateway Protocol). Routers that sit on the
boundary of one AS, and exchange
information with another AS, are called border
or edge routers. In the Cisco operating system,
IBGP routes have an administrative distance
of 200, which is less preferred than either
external BGP or any interior routing protocol.
Other router implementations also prefer
eBGP to IGPs, and IGPs to iBGP.
Optional Extensions negotiated at
Connection Setup
During the OPEN handshake, BGP speakers
can negotiate[1] optional capabilities of the
session, including multiprotocol extensions
and various recovery modes. If the
multiprotocol extensions to BGP [2] are
negotiated at the time of creation, the BGP
speaker can prefix the Network Layer
Reachability Information (NLRI) it advertises
with an address family prefix. These families
include the default IPv4, but also IPv6, IPv4
and IPv6 Virtual Private Networks, and
multicast BGP. Increasingly, BGP is used as a
generalized signaling protocol to carry
information about routes that may not be part
of the global Internet, such as VPNs [3].
Finite state machine
In order to make decisions in its operations
with other BGP peers, a BGP peer uses a
simple finite state machine that consists of six
states: Idle, Connect, Active, OpenSent,
OpenConfirm, and Established. For each peer-
to-peer session, a BGP implementation
maintains a state variable that tracks which of
these six states the session is in. The BGP
protocol defines the messages that each peer
should exchange in order to change the session
from one state to another. The first mode is the
“Idle” mode. In this mode BGP initializes all
resources, refuses all inbound BGP connection
attempts, and initiates a TCP connection to the
peer. The second state is “Connect”. In this
state the router waits for the TCP connection
to complete, transitioning to the "OpenSent"
state if successful. If not, it resets the
ConnectRetry timer and transitions to the
"Active" state upon expiration. In the "Active"
state, the router resets the ConnectRetry timer
to zero, and returns to the "Connect" state.
After "OpenSent," the router sends an Open
message, and waits for one in return.
Keepalive messages are exchanged next, and
upon successful receipt, the router is placed in
the “Established” state. Once established the
router can now send/receive Keepalive,
Update, and Notification messages to/from its
peer.
ROUTING INFORMATION
ROTOCOL
RIP is a distance-vector routing protocol,
which employs the hop count as a routing
metric. The maximum number of hops allowed
with RIP is 15, and the hold down time is 180
seconds. Originally each RIP router transmits
full updates every 30 seconds by default.
Originally, routing tables were small enough
that the traffic was not significant. As
networks grew in size, however, it became
evident there could be a massive burst every
30 seconds, even if the routers had been
initialized at random times. It was thought, as
a result of random initialization, the routing
updates would spread out in time, but this was
not true in practice. Sally Floyd and Van
Jacobson published research in 1994 [1] that
showed having all routers use a fixed 30
second timer was a very bad idea. Without
slight randomization of the update timer, this
research showed that the timers weakly
synchronized over time and sent their updates
out at the same time. Modern RIP
implementations introduce deliberate time
variation into the update timer of each router.
It runs at the network layer of the Internet
protocol suite. RIP prevents routing loops
from continuing indefinitely by implementing
a limit on the number of hops allowed in a
path from the source to a destination. This hop
limit, however, limits the size of networks that
RIP can support. RIP implements the split
horizon and hold down mechanisms to prevent
incorrect routing information from being
propagated. These are some of the stability
features of RIP. In many current networking
environments RIP would not be the first
choice for routing as its convergence times and
scalability are poor compared to EIGRP,
OSPF, or IS-IS (the latter two being link-state
routing protocols), and the hop limit severely
limits the size of network it can be used in. On
the other hand, it is easier to configure
because, using minimal settings for any
routing protocols, RIP does not require any
parameter on a router whereas all the other
protocols require at least one or more
parameters. Architecturally, RIP is a layer
management protocol for what is called the
Internetwork Layer in the Internet protocol
suite or the Network Layer in the OSI
Reference Model. While it is carried in end-to-
end (IPS) or transport layer (OSI) packets,
using port number 520 in the User Datagram
Protocol (UDP), as a routing protocol, it
belongs to the network layer, not the layer that
moves its packets.
IV.CONCLUSION
The project entitled “Network
Communication using pSOS” was successfully
completed and the required reports were
generated. It has been designed to cater the
needs of the organization. The system is
extremely user friendly. Appropriate help is
provided whenever necessary. The system is
developed in Client/Server model and the
system is tested with both live and sample
data. The results of the live data is compacted
with the actual system and verified for its
accuracy. The system is flexible so that there
is a lot of scope to update the system. As the
system is flexible, the system can be changed
if any changes come in future. The system is
portable. Thus, the developed system has been
completed customized for the satisfaction of
the users.

V.REFERENCES Document By
SANTOSH BHARADWAJ REDDY
[1] Jiantao Wang, Lun Li, Steven H.Low and Email: help@matlabcodes.com
John C.Doyle: “Cross-Layer Optimization in
TCP/IP networks,” IEEE/ACM TRANS. ON Engineeringpapers.blo
NETWORKING, 13(3):582-568, JUNE 2005. gspot.com
[2] Mark Bernett and Gene Oleynik: “Uniform More Papers and
communication software using TCP/IP,” Presentations
IEEE/ACM TRANS. ON NETWORKING,
MAY 1999. available on above
[3] J.Borje, H.A Lund: ”Real Time Routers for
site
Wireless Networks,” IEEE TRANS. REAL
TIME, SEP 2003.

[4]Steven H. Low: “A duality model of TCP

and queue management algorithms,”
IEEE/ACM TRANS. On Networking,
11(4):525-536,August 2003.

[5]Jiantao Wang, Lun Li, Steven H. Low , and

John C. Doyle. Can TCP and shortest-path
routing maximize utility? In Proc. Of IEEE
Infocom, April 2003.

[6]Frank P. Kelly, Aman Maulloo, and

David Tan. Rate control for
communication networks: Shadow prices,
proportional fairness and stability. Journal
of Operations Research Society,
49(3):237-252, March 1999.
[7] Behrouz A.Forouzan: “TCP/IP
Protocol Suite”.