Beruflich Dokumente
Kultur Dokumente
AND
RESEARCH CENTRE
Submitted by Submitted to
The Portable Operating System Interface (POSIX)[1] is a family of standards specified by the
IEEE Computer Society for maintaining compatibility between operating systems. POSIX
defines the application programming interface (API), along with command line shells and
utility interfaces, for software compatibility with variants of Unix and other operating
systems.
Originally, the name "POSIX" referred to IEEE Std 1003.1-1988, released in 1988. The
family of POSIX standards is formally designated as IEEE 1003 and the international
standard name is ISO/IEC 9945.
The standards emerged from a project that began circa 1985. Richard Stallman suggested the
name POSIX to the IEEE instead of former IEEE-IX. The committee found it more easily
pronounceable and memorable, and thus adopted it.
Unix was selected as the basis for a standard system interface partly because it was
"manufacturer-neutral". However, several major versions of Unix existed—so there was a
need to develop a common denominator system. The POSIX specifications for Unix-like
operating systems originally consisted of a single document for the core programming
interface, but eventually grew to 19 separate documents (POSIX.1, POSIX.2, etc.).[5] The
standardized user command line and scripting interface were based on the UNIX System V
shell.[6] Many user-level programs, services, and utilities (including awk, echo, ed) were also
standardized, along with required program-level services (including basic I/O: file, terminal,
and network). POSIX also defines a standard threading library API which is supported by
most modern operating systems. In 2008, most parts of POSIX were combined into a single
standard (IEEE Std 1003.1-2008, also known as POSIX.1-2008).
POSIX is based on UNIX System V and Berkeley UNIX, but it is not itself an operating
system.
Instead, POSIX defines the interface between applications and their libraries. POSIX does not
talk about "system calls" or make any distinction between the kernel and the user.
Vendors can adapt any UNIX variant, or even another operating system, to provide POSIX
interfaces. Applications can be moved from one system to another because they see only the
POSIX interface and have no idea what system is under the interface.
An implementation consists of both a set of libraries and an operating system. The POSIX
standard defines only the interface between the application and the library.
POSIX defines how the application talks to the library and how the library and underlying
operating system behave in response. Each implementation can have its own way of dividing
the work between the library and the operating system.
EXPERIMENT NO. 2
1.Man Socket
SYNOPSIS:
#include<sys/types.h>
#include<sys/socket.h>
DESCRIPTION:
The domain parameter specifies a common domain this selects the protocol family which will
be used for communication.
These families are defined in <sys/socket.h>.
FORMAT:
NAME PURPOSE
The socket has the indicated type, which specifies the communication semantics.
TYPES:
1.SOCK_STREAM:
2.SOCK_DGRAM:
3.SOCK_SEQPACKET:
Provides a sequenced , reliable, two-way connection based data transmission path for
datagrams of fixed maximum length.
4.SOCK_RAW:
5.SOCK_RDM:
6.SOCK_PACKET:
2.man connect:
SYNOPSIS:
#include<sys/types.h>
#include<sys/socket.h>
DESCRIPTION:
If the socket is of type SOCK_DGRAM then the serv_addr address is the address to which
datagrams are sent by default and the only addr from which datagrams are received.
If the socket is of type SOCK_STREAM or SOCK_SEQPACKET , this call attempts to make
a connection to another socket.
RETURN VALUE:
ERRORS:
address space.
3.Man Accept
SYNOPSIS:
accept destination(s)
DESCRIPTION:
accept instructs the printing system to accept print jobs to the specified destination.
The –r option sets the reason for rejecting print jobs.
The –e option forces encryption when connecting to the server.
4.Man Send
NAME:
#include<sys/types.h>
#include<sys/socket.h>
ssize_t sendto(int s, const void *buf, size_t len, int flags, const struct sock_addr*to, socklen_t
tolen); ssize_t sendmsg(int s, const struct msghdr *msg, int flags);
DESCRIPTION:
The system calls send, sendto and sendmsg are used to transmit a message to another socket.
The send call may be used only when the socket is in a connected state.
The only difference between send and write is the presence of flags.
The parameter is the file descriptor of the sending socket.
5.Man Recv
SYNOPSIS:
#include<sys/types.h>
#include<sys/socket.h>
ssize_t recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t* from
len); ssize_t recvmsg(int s, struct msghdr *msg, int flags);
DESCRIPTION:
The recvfrom and recvmsg calls are used to receive messages from a socket, and may be used
to recv data on a socket whether or not it is connection oriented.
If from is not NULL, and the underlying protocol provides the src addr , this src addr is filled
in.
The recv call is normally used only on a connection socket and is identical to recvfrom with a
NULL from parameter.
6.Man Read
7.Man Write
SYNOPSIS:
write user[ttyname]
DESCRIPTION:
write allows you to communicate with other users, by copying lines from terminal to
When you run the write and the user you are writing to get a message of the form:
Message from yourname @yourhost on yourtty at hh:mm:…
Any further lines you enter will be copied to the specified user’s terminal.
If the other user wants to reply they must run write as well.
7. Ifconfig
SYNOPSIS:
ifconfig[interface]
DESCRIPTION:
8. Man Bind
SYNOPSIS:
NAME: htonl, htons, ntohl, ntohs - convert values between host and network byte order.
SYNOPSIS:
#include<netinet/in.h>
uint32_t htonl(uint32_t
hostlong); uint16_t
htons(uint32_t hostshort);
uint32_t ntohl(uint32_t
netlong); uint16_t
ntohs(uint16_t netshort);
DESCRIPTION:
The htonl() function converts the unsigned integer hostlong from host byte order to network
byte order.
The htons() converts the unsigned short integer hostshort from host byte order to network
byte order.
The ntohl() converts the unsigned integer netlong from network byte order to host byte order.
SYNOPSIS:
#include<unistd.h>
int gethostname(char *name,size_t len);
DESCRIPTION:
These functions are used to access or to change the host name of the current processor.
NAME: gethostbyname, gethostbyaddr, sethostent, endhostent, herror, hstr – error – get network host
entry.
SYNOPSIS:
#include<netdb.
h> extern int
h_errno;
DESCRIPTION:
The gethostbyname() returns a structure of type hostent for the given hostname.
c) h_addrtype
d) h_length
e) h_addr-list
f) h_addr.
RESULT:
Thus the basic functions used for Socket Programming was studied successfully.
Experiment No: 3(A)
IPv6 and IPv4 are two completely separate protocols. IPv6 is not backwards compatible
with IPv4, and IPv4 hosts and routers will not be able to deal directly with IPv6 traffic (and
vice versa).
Unfortunately, it is a fact of life both that there will be extreme difficulties with address
allocation and routing if the Internet is to continue be run indefinitely using IPv4 and it is
impossible to switch the entire Internet over to IPv6 overnight
Therefore for a long period of time we are going to be dealing with a network in which the
two protocols will be operating side by side. A common estimate of the length of time
involved is 10 years ö in terms of the history of the Internet, a very long time indeed, but
probably a realistic figure in terms of the amount of installed IPv4 software and
infrastructure, all of which will need to be replaced or upgraded.
During the transition period, IPv6 nodes are going to need to communicate with IPv4 nodes,
and isolated 'islands' of IPv6 installations are going to need to use the wider IPv4 network to
connect to each other.
Dual IP stacks have been proposed to solve the first problem, and tunneling to solve the
latter.
Dual IP Stacks
Dual IP Stacks Nodes with dual IP stacks will have both and IPv4 protocol stack and an
IPv6 one. When communicating with IPv6 nodes, they use IPv6 and when communicating
with IPv4 nodes, they revert to IPv4. These nodes have what are called IPv4 compatible
IPv6 addresses - these are addresses where the first 96 bits of the address are zeroes and the
last 32 forms a valid IPv4 address. Every current IPv4 address can be transformed to an
IPv6 address in this way.
Unfortunately, this requires all dual-stack nodes to have IPv4 addresses. This may not be
feasible considering that one of the major reasons for transitioning to IPv6 is that the
available address space is set to run out.
It is also burdensome for routers. Consider a LAN where all hosts are IPv6 enabled, but are
running dual IP stacks to communicate with the outside world. All the network
infrastructure, i.e. routers and bridges etc will need to be able to deal with both protocols,
maintain double routing tables, etc. Simplicity of routing is supposed to be a strength of
IPv6, if this sort of transition mechanism were used it would become a weakness.
To get around these two problems, the following three more advanced transition
mechanisms have been developed. These can be used in situations where a network has
been completely converted to IPv6, but which still needs to communicate with the outside
IPv4 world. They all rely on various servers or devices that sit between the IPv6 and IPv4
networks doing some form of translation.
Dual-stack servers are used as proxies to perform protocol translation with one proxy server
per application (http, ftp, smtp, etc). This has the advantage that very few IPv4 addresses are
required (they are only needed for the proxies), and the protocol translation step may not be
such a large price to pay in situations where firewalls and proxy server already exist, which
is the case in many LANs.
Dedicated hardware devices are placed at thr boundary of the IPv6 network and perform
protocol translation at a low level. To do this, they also store session information. With
NAT-PT, no dual stacks would be needed.
All hosts have dual stacks, but they do not have permanent IPv4 addresses. IPv4 addresses
are temporarily assigned whenever a host contacts or is contacted by and IPv4 host. The
host encapsulates all its IPv4 packets within IPv6 headers to tunnel them over the local IPv6
network. When the DSTM router at the edge of the network sees these packets, they are
decapsulated.
This would find natural uses on networks where IPv4 addresses are already allocated
dynamically.
Tunnelling Tunneling is a mechanism to allow IPv6 domains that are connected via IPv4
networks to communicate with each other, or to allow isolated IPv6 hosts that are not
directly connected to an IPv6 router but only to IPv4 machines to reach the wider IPv6
network. Naturally, to use tunneling a host must have a dual IP stack in order to send and
receive IPv4 datagrams. In most cases, however, this won't apply to large numbers of
machines - just some routers and isolated IPv6 machines on IPv4 networks.
EXPERIMENT NO 3(B)
NAME
SYNOPSIS
#include <sys/file.h>
DESCRIPTION
Apply or remove an advisory lock on the open file specified by fd. The parameter operation
is one of the following:
Tag Description
LOCK_SH Place a shared lock. More than one process may hold a shared lock for a given
file at a given time.
LOCK_EX Place an exclusive lock. Only one process may hold an exclusive lock for a
given file at a given time.
A call to flock() may block if an incompatible lock is held by another process. To make a
non-blocking request, include LOCK_NB (by ORing) with any of the above operations.
A single file may not simultaneously have both shared and exclusive locks.
Locks created by flock() are associated with an open file table entry. This means that
duplicate file descriptors (created by, for example, fork(2) or dup(2)) refer to the same lock,
and this lock may be modified or released using any of these descriptors. Furthermore, the
lock is released either by an explicit LOCK_UN operation on any of these duplicate
descriptors, or when all such descriptors have been closed.
If a process uses open(2) (or similar) to obtain more than one descriptor for the same file,
these descriptors are treated independently by flock(). An attempt to lock the file using one
of these file descriptors may be denied by a lock that the calling process has already placed
via another descriptor.
A process may only hold one type of lock (shared or exclusive) on a file. Subsequent flock()
calls on an already locked file will convert an existing lock to the new lock mode.
A shared or exclusive lock can be placed on a file regardless of the mode in which the file
was opened.
RETURN VALUE
ERRORS
EINTR While waiting to acquire a lock, the call was interrupted by delivery of a
signal caught by a handler.
ENOLCK The kernel ran out of memory for allocating lock records.
EWOULDBLOCK The file is locked and the LOCK_NB flag was selected.
CONFORMING TO
4.4BSD (the flock(2) call first appeared in 4.2BSD). A version of flock(2), possibly
implemented in terms of fcntl(2), appears on most Unices.
EXPERIMENT NO. 3(C)
Ns began as a variant of the REAL network simulator in 1989 and has evolved substantially
over the past few years. In 1995 ns development was supported by DARPA through the
VINT project at LBL, Xerox PARC, UCB, and USC/ISI. Currently ns development is
support through DARPA with SAMAN and through NSF with CONSER, both in
collaboration with other researchers including ACIRI. Ns has always included substantal
contributions from other researchers, including wireless code from the UCB Daedelus and
CMU Monarch projects and Sun Microsystems.
While we have considerable confidence in ns, ns is not a polished and finished product, but
the result of an on-going effort of research and development. In particular, bugs in the
software are still being discovered and corrected. Users of ns are responsible for verifying
for themselves that their simulations are not invalidated by bugs. We are working to help the
user with this by significantly expanding and automating the validation tests and demos.
Similarly, users are responsible for verifying for themselves that their simulations are not
invalidated because the model implemented in the simulator is not the model that they were
expecting.
Mweigle - Provide fixes to the Tmix traffic generator, mainly to the one-way TCP
implementation, but some changes to the Full-TCP version as well. Tmix with one-way
TCP now performs comparably to Tmix with Full-TCP (albeit with longer running times
and higher memory consumption). Includes contributions from David Hayes and DongXia
Xu at Swinburne and relevant updates to the documentation and tests.
What is vi?
The default editor that comes with the UNIX operating system is called vi (visual editor).
[Alternate editors for UNIX environments include pico and emacs, a product of GNU.]
The UNIX vi editor is a full screen editor and has two modes of operation:
1. Command mode commands which cause action to be taken on the file, and
In the command mode, every character typed is a command that does something to the text
file being edited; a character typed in the command mode may even cause the vi editor to
enter the insert mode. In the insert mode, every character typed is added to the text in the
file; pressing the <Esc> (Escape) key turns off the Insert mode.
While there are a number of vi commands, just a handful of these is usually sufficient for
beginning vi users. To assist such users, this Web page contains a sampling of
basic vi commands. The most basic and useful commands are marked with an asterisk (* or
star) in the tables below. With practice, these commands should become automatic.
NOTE: Both UNIX and vi are case-sensitive. Be sure not to use a capital letter in place of a
lowercase letter; the results will not be what you expect.
To Start vi
To use vi on a file, type in vi filename. If the file named filename exists, then the first page
(or screen) of the file will be displayed; if the file does not exist, then an empty file and
screen are created into which you may enter text.
vi -r filename recover filename that was being edited when system crashed
To Exit vi
Usually the new or modified file is saved when you leave vi. However, it is also possible to
quit vi without saving the file.
Note: The cursor moves to bottom of screen whenever a colon (:) is typed. This type of
command is completed by hitting the <Return> (or <Enter>) key.
* :x<Return> quit vi, writing out modified file to file named in original invocation
:wq<Return> quit vi, writing out modified file to file named in original invocation
* :q!<Return> quit vi even though latest changes have not been saved for this vi call
Unlike many of the PC and MacIntosh editors, the mouse does not move the cursor within
the vi editor screen (or window). You must use the the key commands listed below. On
some UNIX platforms, the arrow keys may be used as well; however, since vi was designed
with the Qwerty keyboard (containing no arrow keys) in mind, the arrow keys sometimes
produce strange effects in vi and should be avoided.
If you go back and forth between a PC environment and a UNIX environment, you may find
that this dissimilarity in methods for cursor movement is the most frustrating difference
between the two.
In the table below, the symbol ^ before a letter means that the <Ctrl> key should be held
down while the letter key is pressed.
j or <Return>
* move cursor down one line
[or down-arrow]
h or <Backspace>
* move cursor left one character
[or left-arrow]
l or <Space>
* move cursor right one character
[or right-arrow]
* 0 (zero) move cursor to start of current line (the one with the cursor)
Screen Manipulation
The following commands allow the vi editor screen (or window) to move up or down
several lines and to be refreshed.
Unlike PC editors, you cannot replace or delete text by highlighting it with the mouse.
Instead use the commands in the following tables.
Perhaps the most important command is the one that allows you to back up and undo your
last action. Unfortunately, this command acts like a toggle, undoing and redoing your most
recent action. You cannot go back more than one step.
The main purpose of an editor is to create, add, or modify text for a file.
The following commands allow you to insert and add text. Each of these commands puts
the vi editor into insert mode; thus, the <Esc> key must be pressed to terminate the entry of
text and to put the vi editor back into command mode.
* O open and put text in a new line above current line, until <Esc> hit
Changing Text
R replace characters, starting with current cursor position, until <Esc> hit
change N words beginning with character under cursor, until <Esc> hit;
cNw
e.g., c5w changes 5 words
C change (replace) the characters in the current line, until <Esc> hit
cc change (replace) the entire current line, stopping when <Esc> is hit
change (replace) the next N lines, starting with the current line,
Ncc or cNc
stopping when <Esc> is hit
Deleting Text
D delete the remainder of the line, starting with current cursor position
Nyy or yNy copy (yank, cut) the next N lines, including the current line, into the buffer
p put (paste) the line(s) in the buffer into the text after the current line
Other Commands
Searching Text
A common occurrence in text editing is to replace one word or phase by another. To locate
instances of particular sets of characters (or strings), use the following commands.
Being able to determine the line number of the current line or the total number of lines in the
file being edited is sometimes useful.
provides the current line number, along with the total number of lines,
^g
in the file at the bottom of the screen
These commands permit you to input and output files other than the named file with which
you are currently working.
AIM - Program for TCP Connection of Client and Server on Single System
Server Side
#include<sys/types.h>
#include<sys/socket.h>
#include<netinet/in.h>
#include<netdb.h>
#include<arpa/inet.h>
#include<string.h>
int
bd,sd,ad;
char
buff[1024]
;
struct sockaddr_in
cliaddr,servaddr; socklen_t
clilen; clilen=sizeof(cliaddr);
bzero(&servaddr,sizeof(serv
addr));
sd=socket(AF_INET,SOCK_STREAM,0);
/*Bind function assigns a local protocol address to the
socket*/ bd=bind(sd,(struct
sockaddr*)&servaddr,sizeof(servaddr));
listen(sd,5);
printf("Server is running….\n");
ad=accept(sd,(struct
sockaddr*)&cliaddr,&clilen); while(1)
bzero(&buff,sizeof(buff));
}
}
Client Side
#include<stdio.h>
#include<string.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<unistd.h>
#include<netinet/in.h>
#include<netdb.h>
#include<arpa/inet.h>
int
cd,sd,ad;
char
buff[1024]
;
bzero(&servaddr,sizeof(servaddr));
memcpy((char *)&servaddr.sin_addr.s_addr,h->h_addr_list[0],h-
>h_length); servaddr.sin_port = htons(1999);
while(1)
send(sd,buff,sizeof(buff)
+1,0); printf("\n Data
Sent ");
//recv(sd,buff,strlen(buff
)+1,0); printf("%s",buff);
}
EXPERIMENT NO. 5
AIM - Program for UDP Connection for Client Server on Single System
Server Side
#include<sys/socket.h>
#include<stdio.h>
#include<unistd.h>
#include<string.h>
#include<netinet/in.h>
#include<netdb.h>
#include<arpa/inet.h>
#include<sys/types.h>
int sd;
char buff[1024];
/*UDP socket is created, an Internet socket address structure is filled with wildcard
sd=socket(AF_INET,SOCK_DGRAM,0);
if (sd<0)
bzero(&servaddr,sizeof(servaddr));
servaddr.sin_family=AF_INET;
servaddr.sin_addr.s_addr=htonl(INADDR_ANY);
servaddr.sin_port=htons(5669);
if(bind(sd,(struct sockaddr*)&servaddr,sizeof(servaddr))<0)
exit(1);
printf("%s","Server is Running…\n");
while(1)
bzero(&buff,sizeof(buff));
/*Sendto function is used to echo the message from server to client side*/
if(sendto(sd,buff,sizeof(buff),0,(struct sockadddr*)&cliaddr,clilen)<0)
close(sd); return 0;
}
Client Side
#include<sys/types.h>
#include<sys/socket.h>
#include<stdio.h>
#include<unistd.h>
#include<string.h>
#include<netinet/in.h>
#include<netdb.h>
int sd;
char buff[1024];
/*UDP socket is created, an Internet socket address structure is filled with wildcard
address & server’s well known port*/
sd = socket(AF_INET,SOCK_DGRAM,0); if(sd<0)
bzero(&servaddr,len);
while(1)
{
/*sendto is used to transmit the request message to the server*/ if(sendto (sd,buff,sizeof
(buff),0,(struct sockaddr*)&servaddr,len)<0)
close(sd); return 0;
}
EXPERMENT NO. 6
Server Side
import java.io.*;
import java.net.*;
ServerSocket ss;
Socket s;
DataInputStream dis;
DataOutputStream dos;
public MyServer1()
try
System.out.println("Server Started");
ss=new ServerSocket(10);
s=ss.accept();
System.out.println(s);
System.out.println("CLIENT CONNECTED");
ServerChat();
}
catch(Exception e)
System.out.println(e);
new MyServer1();
do
str=dis.readUTF();
System.out.println("Client Message:"+str);
s1=br.readLine();
dos.writeUTF(s1);
dos.flush();
while(!s1.equals("bye"));
}
Client Side
import java.io.*;
import java.net.*;
Socket s;
DataInputStream din;
DataOutputStream dout;
public MyClient1()
try
//s=new Socket("10.10.0.3,10");
s=new Socket("localhost",10);
System.out.println(s);
ClientChat();
catch(Exception e)
System.out.println(e);
{
BufferedReader br= new BufferedReader(new InputStreamReader(System.in));
String s1;
do
s1=br.readLine();
dout.writeUTF(s1);
dout.flush();
System.out.println("Server Message:"+din.readUTF());
while(!s1.equals("stop"));
new MyClient1();
}
EXPERIMENT NO. 7
Server Side
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int main()
int sock;
char message[512];
exit(1);
}
serverAdd.sin_family = AF_INET;
serverAdd.sin_port = htons(5000);
serverAdd.sin_addr.s_addr = INADDR_ANY;
bzero(&(serverAdd.sin_zero),8);
perror("Bind Error");
exit(1);
fflush(stdout);
while (1)
message[TotalByte] = '\0';
fflush(stdout);
return 0;
}
Client Side
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int main()
int sock;
char sendMessage[512];
exit(1);
serverAdd.sin_family = AF_INET;
serverAdd.sin_port = htons(5000);
while (1)
fgets(sendMessage,100,stdin);