Beruflich Dokumente
Kultur Dokumente
This project has a wide application as one can control the device from
any remote location by just giving control signals to the server ARM processor
through a desktop or other ARM processor which can be treated as client.
The introduction of Linux in the cyber world has given relief to the system
administrators because of its security features. It has got rich features for the
networking and the security. One of the oldest and well-known technique to
transfer the data is File Transfer Protocol. In this project we have equipped a
model FTP with a security check tool, which allows the communication
between the client and the server only after performing the security check, in
the form of user name and password. This project helps us to have a secured
way of the data transmission using sockets in Linux.
Why Linux?
Performance: Linux is efficient and fast, and makes excellent use of hardware.
Fast and responsive the system is, even with many processes running and with
multiple windows open. Linux is commonly used in high-end server
environments where this kind of hardware is the norm. Linux is used for
building large "clusters" consisting of hundreds of machines connected with a
fast network, used f or massive scientific calculations or for driving large web
sites.
Flexibility and Free: Since its licensed under GNU its code is open so each and
every user can access even the internal parts of the code for free of cost and he
can modify it as per his/ her needs. Adding modules can modify even the kernel,
which is said to be the core of the operating system.
Secured: This is supposed to be the most secured at almost free of cost operating
system that ever created. And it’s free from viruses, worms, and Trojans. It’s
secured from the virus in the “.exe” format because these files are not executed
in Linux.
Why FTP?
FTP is implemented using TCP and Advantages of TCP over UDP is as follows.
TCP also provides reliability. When TCP sends data to the other end, it requires
an acknowledgment in return. If an acknowledgment is not received, TCP
automatically retransmits the data and waits a longer amount of time. After
some number of retransmissions, TCP will give up, with the total amount of
time spent trying to send data typically between 4 and10 minutes (depending
on the implementation).It delivers data to the other endpoint if possible, and
notifies the user (by giving up on retransmissions and breaking the connection)
if it is not possible. Therefore, TCP cannot be described as a 100% reliable
protocol; It provides reliable delivery of data or reliable notification of failure.
TCP contains algorithms to estimate the round-trip time
(RTT) between a client and server dynamically so that it
knows how long to wait for an acknowledgment.
FTP: In FTP two types of connections are established between client & server.
Data connection & control connection. Data connection is used to transfer data
while control connection is used to transfer commands. Control link is always
there whether data is being transmitted or not while data link is released on
the completion of data transfer. FTP runs exclusively over TCP. It defaults to
listen on port 21 for incoming connections from FTP clients. A connection to
this port from the FTP Client forms the control stream on which commands are
passed from the FTP client to the FTP server and on occasion from the FTP
server to the FTP client. FTP uses out-of-band control, which means it uses a
separate connection for control and data. Thus, for the actual file transfer to
take place, a different connection is required which is called the data stream.
Depending on the transfer mode, the process of setting up the data stream is
different. Port 21 for control (or program), port 20 for data.But this project is a
model implementaion of the FTP protocol so we have used a different port
number those are unused and free to user for the command and data. In active
mode, the FTP client opens a dynamic port, sends the FTP server the dynamic
port number on which it is listening over the control stream and waits for a
connection from the FTP server. When the FTP server initiates the data
connection to the FTP client it binds the source port to port 20 on the FTP
server. In order to use active mode, the client sends a PORT command, with the
IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2".
Each field is a decimal representation of 8 bits of the host IP, followed by the
chosen data port. For example, a client with an IP of 192.168.0.1, listening on
port 49154 for the data connection will send the command "PORT
192,168,0,1,192,2". The port fields should be interpreted as p1×256 + p2 =
port, or, in this example, 192×256 + 2 = 49154.
In passive mode, the FTP server opens a dynamic port, sends the FTP client
the server's IP address to connect to and the port on which it is listening (a 16-
bit value broken into a high and low byte, as explained above) over the control
stream and waits for a connection from the FTP client. In this case, the FTP
client binds the source port of the connection to a dynamic port. To use passive
mode, the client sends the PASV command to which the server would reply with
something similar to "227 Entering Passive Mode (127,0,0,1,192,52)". The
syntax of the IP address and port are the same as for the argument to the PORT
command. In extended passive mode, the FTP server operates exactly the
same as passive mode, however it only transmits the port number (not broken
into high and low bytes) and the client is to assume that it connects to the same
IP address that was originally connected to. Extended passive mode was added
by RFC 2428 in September 1998. While data is being transferred via the data
stream, the control stream sits idle. This can cause problems with large data
transfers through firewalls which time out sessions after lengthy periods of
idleness. While the file may well be successfully transferred, the control session
can be disconnected by the firewall, causing an error to be generated. In ASCII
mode (see below), resuming transfers can be troublesome if client and server
use different end of line characters.
The objectives of FTP, as outlined by its RFC, are:
1. To promote sharing of files (computer programs and/or data).
2. To encourage indirect or implicit use of remote computers.
3. To shield a user from variations in file storage systems among different host.
4. To transfer data reliably, and efficiently.
Security problems:
The original FTP specification is an inherently insecure method of transferring
files because there is no method specified for transferring data in an encrypted
fashion. This means that under most network configurations, user names,
passwords, FTP commands and transferred files can be "sniffed" or viewed by
anyone on the same network using a packet sniffer. This is a problem common
to many Internet protocol specifications written prior to the creation of SSL
such as HTTP, SMTP and Telnet. The common solution to this problem is to use
either SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL), which adds
SSL or TLS encryption to FTP as specified in RFC 4217
Data format of FTP:
While transferring data over the network, several data representations can be
used. The two most common transfer modes are:
1. ASCII mode
2. Binary mode: In "Binary mode", the sending machine sends each file byte for
byte and as such the recipient stores the bytestream as it receives it. (The FTP
standard calls this "IMAGE" or "I" mode)
In "ASCII mode", any form of data that is not plain text will be corrupted. When
a file is sent using an ASCII-type transfer, the individual letters, numbers, and
characters are sent using their ASCII character codes. The receiving machine
saves these in a text file in the appropriate format (for example, a Unix machine
saves it in a Unix format, a Windows machine saves it in a Windows format).
Hence if an ASCII transfer is used it can be assumed plain text is sent, which is
stored by the receiving computer in its own format. Translating between text
formats might entail substituting the end of line and end of file characters used
on the source platform with those on the destination platform, e.g. a Windows
machine receiving a file from a Unix machine will replace the line feeds with
carriage return-line feed pairs. It might also involve translating characters; for
example, when transferring from an IBM mainframe to a system using ASCII,
EBCDIC characters used on the mainframe will be translated to their ASCII
equivalents, and when transferring from the system using ASCII to the
mainframe, ASCII characters will be translated to their EBCDIC equivalents. By
default, most FTP clients use ASCII mode. Some clients try to determine the
required transfer-mode by inspecting the file's name or contents, or by
determining whether the server is running an operating system with the same
text file format. The FTP specifications also list the following transfer modes:
1. EBCDIC mode - this transfers bytes, except they are encoded in EBCDIC
rather than ASCII. Thus, for example, the ASCII mode server
2. Local mode - this is designed for use with systems that are word-oriented
rather than byte-oriented. For example mode "L 36" can be used to transfer
binary data between two 36-bit machines. In L mode, the words are packed
into bytes rather than being padded. Given the predominance of byte-oriented
hardware nowadays, this mode is rarely used. However, some FTP servers
accept "L 8" as being equivalent to "I".
In practice, these additional transfer modes are rarely used. They are however
still used by some legacy mainframe systems. The text (ASCII/EBCDIC) modes
can also be qualified with the type of carriage control used (e.g. TELNET NVT
carriage control, ASA carriage control), although that is rarely used nowadays.
Note that the terminology "mode" is technically incorrect, although commonly
used by FTP clients. "MODE" in RFC 959 refers to the format of the protocol
data stream (STREAM, BLOCK or COMPRESSED), as opposed to the format of
the underlying file. What is commonly called "mode" is actually the "TYPE",
which specifies the format of the file rather than the data stream. FTP also
supports specification of the file structure ("STRU"), which can be either FILE
(stream-oriented files), RECORD (record-oriented files) or PAGE (special type
designed for use with TENEX). PAGE STRU is not really useful for non-TENEX
systems, and RFC1123 section 4.1.2.3 recommends that it not be implemented.
Open: This is the first basic command that has to be given to open the
communication channel between the client and the server.
Download from client (get): This command is used to download any file
from the server to the client side. On giving this command this will ask for the
file name that you want to search for from the server. Once if it got the file it
will give you or it will return an error. The actual process that’s happening here
is it taken a copy of the file from the server side and it create a file in the client
side wit the same permission. The copy of the file that’s been taken will be
there in the data socket it will be written to the created file.
Uploading to the server (put): This command performs the inverse job
of the get command that’s it will upload the particular file to the server side.
First it will create a create a file of the same name` and the then it will read the
contents of the file and store it in a particular buffer and then the buffer will be
transmitted and stored in the server side.
Sockets are created and used differently from pipes because they make a clear
distinction between client and server. The socket mechanism can implement
multiple clients attached to a single server. Socket Connections we can think of
socket connections as telephone calls into a busy building. A call comes into an
organization and is answered by a receptionist who puts the call through to the
correct department (the server process) and from there to the right person
(the server socket). Each incoming call (client) is routed to appropriate end
point and the intervening operators are free to deal with further calls. Before
you look at the way socket connections are established in Linux systems, you
need to understand how they operate for socket applications that maintain a
connection. 1) First of all, a server application creates a socket, which like a file
descriptor is a resource assigned to the server process and that process alone.
The server creates it using the system call socket, and it can’t be shared with
other processes. 2) Next, the server process gives the socket a name. Local
sockets are given a filename in the Linux file system often to be found in /tmp
or /usr/tmp. For network sockets, the filename will be a service identifier(port
number/access point) relevant to the particular network to which the clients
can connect. This identifier allows Linux to route incoming connections
specifying a particular port number to the correct server process. A socket is
named using the system call bind. The server process then waits for a client to
connect to the named socket. 3) The system call, listen, creates a queue for
incoming connections. 4) The server can accept them using the system call
accept .When the server calls accept, a new socket is created that is distinct
from the named socket. This new socket is used solely for communication with
this particular client. The named socket remains for further connections from
other clients. The server can take advantage of multiple connections. For a
simple server, further clients wait on the listen queue until the server is ready
again. 5) The client side of a socket-based system is more straightforward. The
client creates an unnamed socket by calling socket. It then calls connect to
establish a connection with the server by using the server’s named socket as an
address. Once established, sockets can be used like low-level file descriptors,
providing two-way data communications.
The function will return 0 on success and –1 in case of the failure. The client
does not have to call bind before calling connect: the kernel will choose both an
ephemeral port and the source IP address if necessary. In the case of a TCP
socket, the connect function initiates TCP's three-way handshake the function
returns only when the connection is established or an error occurs. There are
several different error returns possible. 1. If the client TCP receives no
response to its SYN segment, ETIMEDOUT is returned. 4.4BSD, for example,
sends one SYN when connect is called, another 6 seconds later, and another 24
seconds later If no response is received after a total of 75 seconds, the error is
returned. Some systems provide administrative control over this timeout. If the
server's response to the client's SYN is a reset (RST), this indicates that no
process is waiting for connections on the server host at the port specified This
is a hard error and the error ECONNREFUSED is returned to the client as soon
as the RST is received. An RST is a type of TCP segment that is sent by TCP
when something is wrong. Three conditions that generate an RST are: when a
SYN arrives for a port that has no listening server when TCP wants to abort an
existing connection, and when TCP receives a segment for a connection that
does not exist. 3. If the client's SYN elicits an ICMP "destination unreachable"
from some intermediate router, this is considered a soft error. The client kernel
saves the message but keeps sending SYNs with the same time between each
SYN as in the first scenario. If no response is received after some fixed amount
of time (75 seconds for 4.4BSD), the saved ICMP error is returned to the
process as either EHOSTUNREACH or ENETUNREACH. It is also possible that
the remote system is not reachable by any route in the local system's
forwarding table, or that the connect call returns without waiting at all.
Bind Function: Protocol address = IP address + Port address. The
bind function assigns a local protocol address to a socket. With the Internet
protocols, the protocol address is the combination of either a 32-bit IPv4
address or a 128-bit IPv6 address, along with a 16-bit TCP or UDP port number.
Historically, the man page description of bind has said, "bind assigns a name to
an unnamed socket." The use of the term "name" is confusing and gives the
connotation of domain names. The bind function has nothing to do with names.
bind assigns a protocol address to a socket, and what that protocol address
means depends on the protocol. The second argument is a pointer to a
protocol-specific address, and the third argument is the size of this address
structure. With TCP, calling bind lets us specify a port number, an IP address,
both, or neither. _ Servers bind their well-known port when they start. This, the
kernel chooses an ephemeral port for the socket when either connect or listen
is called. It is normal for a TCP client to let the kernel choose an ephemeral
port, unless the application requires a reserved port but it is rare for a TCP
server to let the kernel choose an ephemeral port, since their well-known port
knows servers. Exceptions to this rule are Remote Procedure Call (RPC)
servers. They normally let the kernel choose an ephemeral port for their
listening socket since this port is then registered with the RPC port mapper.
Clients have to contact the port mapper to obtain the ephemeral port before
they can connect to the server. This also applies to RPC servers using UDP. A
process can bind a specific IP address to its socket. The IP address must belong
to an interface on the host. For a TCP client, this assigns the source IP address
that will be used for IP datagrams sent on the socket. For a TCP server, this
restricts the socket to receive incoming client connections destined only to that
IP address. Normally, a TCP client does not bind an IP address to its socket. The
kernel chooses the source IP address when the socket is connected, based on
the outgoing interface that is used, which in turn is based on the route required
to reach the server If a TCP server does not bind an IP address to its socket, the
kernel uses the destination IP address of the client's #include <sys/socket.h>
int bind (int sockfd, const struct sockaddr *myaddr, socklen_t addrlen); It will
also return 0 on success and a negative value on failure.
Listen Function: The listen function is called only by a TCP server
and it performs two actions: 1. When a socket is created by the socket function,
it is assumed to be an active socket, that is, a client socket thatwill issue a
connect. The listen function converts an unconnected socket into a passive
socket, indicating that the kernel should accept incoming connection requests
directed to this socket. In terms of the TCP state transition diagram the call to
listen moves the socket from the CLOSED state to the LISTEN state. 2. The
second argument to this function specifies the maximum number of
connections the kernel should queue for this socket. #include <sys/socket.h>
#int listen (int sockfd, int backlog); Returns 0 on success and –1 on failure. This
function is normally called after both the socket and bind functions and must
be called before calling the accept function. To understand the backlog
argument, we must realize that for a given listening socket, the kernel
maintains two queues: 1. An incomplete connection queue, which contains an
entry for each SYN that has arrived from a client for which the server is
awaiting completion of the TCP three-way handshake. 2. A completed
connection queue, which contains an entry for each client with whom the TCP
three-way handshake has completed. These sockets are in the ESTABLISHED
state
When an entry is created on the incomplete queue, the parameters from the
listen socket are copied over to the newly created connection. The connection
creation mechanism is completely automatic; the server process is not
involved. Depicts the packets exchanged during the connection establishment
with these two queues.
When a SYN arrives from a client, TCP creates a new entry on the incomplete
queue and then responds with the second segment of the three-way
handshake: the server's SYN with an ACK of the client's SYN. This entry will
remain on the incomplete queue until the third segment of the three-way
handshake arrives (the client's ACK of the server's SYN), or until the entry
times out. (Berkeley-derived implementations have a timeout of 75 seconds for
these incomplete entries.) If the three-way handshake completes normally, the
entry moves from the incomplete queue to the end of the completed queue.
When the process calls accept, which we will describe in the next section, the
first entry on the completed queue is returned to the process, or if the queue is
empty, the process is put to sleep until an entry is placed onto the completed
queue. There are several points to consider regarding the handling of these two
queues. The backlog argument to the listen function has historically specified
the maximum value for the sum of both queues. There has never been a formal
definition of what the backlog means. The 4.2BSD man page says that it
"defines the maximum length the queue of pending connections may grow to."
Many man pages and even the POSIX specification copy this definition
verbatim, but this definition does not say whether a pending connection is one
in the SYN_RCVD state, one in the ESTABLISHED state that has not yet been
accepted, or either. The historical definition in this bullet is the Berkeley
implementation, dating back to 4.2BSD, and copied by many others.
close Function: The normal Unix close function is also used to close a
socket and terminate a TCP connection #include <unistd.h> int close (int
sockfd); This will return 0 on the success and –1 on the failure. The default
action of close with a TCP socket is to mark the socket as closed and return to
the process immediately. The socket descriptor is no longer usable by the
process: It cannot be used as an argument to read or write. But, TCP will try to
send any data that is already queued to be sent to the other end, and after this
occurs, the normal TCP connection termination sequence takes place
AT91SAM9260
MICROCONTROLLER
• Incorporates the ARM926EJ-S™ ARM® Thumb® Processor
– DSP Instruction Extensions, ARM Jazelle® Technology for Java® Acceleration
– 8-KByte Data Cache, 8-KByte Instruction Cache, Write Buffer
– 200 MIPS at 180 MHz
– Memory Management Unit
– EmbeddedICE™, Debug Communication Channel Support
• Additional Embedded Memories
– One 32-KByte Internal ROM, Single-cycle Access At Maximum Matrix Speed
– Two 4-KByte Internal SRAM, Single-cycle Access At Maximum Matrix Speed
• External Bus Interface (EBI)
– Supports SDRAM, Static Memory, ECC-enabled NANDFlash and CompactFlash®
• USB 2.0 Full Speed (12 Mbits per second) Device Port
– On-chip Transceiver, 2,432-byte Configurable Integrated DPRAM
• USB 2.0 Full Speed (12 Mbits per second) Host Single Port in the 208-lead PQFP
Package and Double Port in 217-ball LFBGA Package
– Single or Dual On-chip Transceivers
– Integrated FIFOs and Dedicated DMA Channels
• Ethernet MAC 10/100 Base T
– Media Independant Interface or Reduced Media Independant Interface
– 28-byte FIFOs and Dedicated DMA Channels for Receive and Transmit
• Image Sensor Interface
– ITU-R BT. 601/656 External Interface, Programmable Frame Capture Rate
– 12-bit Data Interface for Support of High Sensibility Sensors
– SAV and EAV Synchronization, Preview Path with Scaler, YCbCr Format
• Bus Matrix
– Six 32-bit-layer Matrix
– Boot Mode Select Option, Remap Command
• Fully-featured System Controller, including
– Reset Controller, Shutdown Controller
– Four 32-bit Battery Backup Registers for a Total of 16 Bytes
– Clock Generator and Power Management Controller
– Advanced Interrupt Controller and Debug Unit
– Periodic Interval Timer, Watchdog Timer and Real-time Timer
• Reset Controller (RSTC)
– Based on a Power-on Reset Cell, Reset Source Identification and Reset Output
Board Description
3-2 AT91SAM9260-EK Evaluation Board User Guide
6234C–ATARM–22-Mar-07
Control
• Clock Generator (CKGR)
– Selectable 32768Hz Low-power Oscillator or Internal Low Power RC Oscillator on
Battery Backup Power Supply, Providing a Permanent Slow Clock
– 3 to 20 MHz On-chip Oscillator, One up to 240 MHz PLL and One up to 130 MHz
PLL
• Power Management Controller (PMC)
– Very Slow Clock Operating Mode, Software Programmable Power Optimization
Capabilities
– Two Programmable External Clock Signals
• Advanced Interrupt Controller (AIC)
– Individually Maskable, Eight-level Priority, Vectored Interrupt Sources
– Three External Interrupt Sources and One Fast Interrupt Source, Spurious
Interrupt Protected
• Debug Unit (DBGU)
– 2-wire UART and Support for Debug Communication Channel, Programmable
ICE Access Prevention
• Periodic Interval Timer (PIT)
– 20-bit Interval Timer plus 12-bit Interval Counter
• Watchdog Timer (WDT)
– Key-protected, Programmable Only Once, Windowed 16-bit Counter Running at
Slow Clock
• Real-time Timer (RTT)
– 32-bit Free-running Backup Counter Running at Slow Clock with 16-bit Prescaler
• One 4-channel 10-bit Analog-to-Digital Converter
• Three 32-bit Parallel Input/Output Controllers (PIOA, PIOB, PIOC)
– 96 Programmable I/O Lines Multiplexed with up to Two Peripheral I/Os
– Input Change Interrupt Capability on Each I/O Line
– Individually Programmable Open-drain, Pull-up Resistor and Synchronous Output
– High-current Drive I/O Lines, Up to 16 mA Each
• Peripheral DMA Controller Channels (PDC)
• One Two-slot MultiMedia Card Interface (MCI)
– SDCard/SDIO and MultiMediaCard™ Compliant
– Automatic Protocol Control and Fast Automatic Data Transfers with PDC
• One Synchronous Serial Controller (SSC)
– Independent Clock and Frame Sync Signals for Each Receiver and Transmitter
– I²S Analog Interface Support, Time Division Multiplex Support
– High-speed Continuous Data Stream Capabilities with 32-bit Data Transfer
• Four Universal Synchronous/Asynchronous Receiver Transmitters (USART)
– Individual Baud Rate Generator, IrDA® Infrared Modulation/Demodulation,
Manchester Encoding/Decoding
– Support for ISO7816 T0/T1 Smart Card, Hardware Handshaking, RS485 Support
– Full Modem Signal Control on USART0
• Two 2-wire UARTs
• Two Master/Slave Serial Peripheral Interfaces (SPI)
– 8- to 16-bit Programmable Data Length, Four External Peripheral Chip Selects
– Synchronous Communications
• Two Three-channel 16-bit Timer/Counters (TC)
– Three External Clock Inputs, Two Multi-purpose I/O Pins per Channel
– Double PWM Generation, Capture/Waveform Mode, Up/Down Capability
Microcontroller
! One LFBGA 217-ball fitted on board
! One LQFP 208-lead footprint
To try the microcontroller in the LQFP package, the user has to unsolder MN4 and solder
the PQFP208 microcontroller on the MN6 footprint.
3.5 Clock Circuitry ! 18.432 MHz standard crystal for the embedded oscillator
! Selectable 32768Hz Low-power external standard crystal Oscillator or Internal Low
Power RC Oscillator
3.6 Reset Circuitry ! Internal reset controller with bi-directional reset pin
! External reset pushbutton
Circuitry
! On-board 1.8V High Efficiency step-down charge pump regulator with shutdown
control
! On-board 3.3V linear regulator with shutdown control
3.9 Remote
Communication
! One serial interface (DBGU COM Port) via RS-232 DB9 male socket
! One complete modem serial interface (COM Port 0) via RS-232 DB9 male socket
! One additional serial interface (COM Port 1) with RTS/CTS handshake control via
RS-232 DB9 male socket
! USB V2.0 full-speed compliant, 12 Mbits per second (UDP)
! Two(1) USB Host ports V2.0 full-speed compliant, 12 Mbits per second (UHP)
! One Ethernet 100-base TX with three status LEDs
Board Description
3-6 AT91SAM9260-EK Evaluation Board User Guide
6234C–ATARM–22-Mar-07
CLIENT SERVER
Connection Request
Authentication
query
Authentication Reply
Success Ack
Switching Command
Switching Command
Switching Command
RELAY
CODING
SERVER CODE
#include<stdio.h>
#include<errno.h>
#include<sys/types.h>
#include<sys/socket.h>
#include<netinet/in.h>
#include<sys/wait.h>
#include<string.h>
#include<sys/stat.h>
#include<fcntl.h>
#define BACKLOG 5
char logg[32];
char pass[32];
}data_log;
data_log log[4];
char sen_uacck1[15];
char logg_name[32];
char pass_word[32];
int put_serv(int,int);
int get_serv(int,int);
char help_buff[200];
int sin_size,pol;
int len,len1;
char servbuf[800];
char *comr[2];
char comr1[20];
int recvedb;
char open2[32];
int ffd;
FILE *ffd1;
FILE *filefd;
main()
int i;
comr[1]= (char*)0;
memset(open2,0,20);
//************************************************************
// control socket
//************************************************************
if((sockfd_cmd = socket(AF_INET,SOCK_STREAM,0))==-1)
perror("socket");
exit(1);
my_addr.sin_family=AF_INET;
my_addr.sin_port=htons(MYPORT);
my_addr.sin_addr.s_addr=INADDR_ANY;
bzero(&(my_addr.sin_zero),8);
if((sockfd_data=socket(AF_INET,SOCK_STREAM,0))==-1)
exit(1);
my_data_addr.sin_family=AF_INET;
my_data_addr.sin_port=htons(DATAPORT);
my_data_addr.sin_addr.s_addr=INADDR_ANY;
bzero(&(my_data_addr.sin_zero),8);
perror("bind");
exit(1);
exit(1);
if(listen(sockfd_cmd,BACKLOG)==-1)
exit(1);
if(listen(sockfd_data,BACKLOG)==-1)
exit(1);
strcpy(log[0].pass,"akm1");
strcpy(log[1].logg,"akm2");
strcpy(log[1].pass,"akm2");
strcpy(log[2].logg,"akm3");
strcpy(log[2].pass,"akm3");
strcpy(log[3].logg,"akm4");
strcpy(log[3].pass,"akm4");
memset(servbuf,0,MAX);
memset(comr1,0,20);
sin_size=sizeof(struct sockaddr_in);
// break;
if(flag==0)
memset(logg_name,0,32);
memset(pass_word,0,32);
memset(open2,0,32);
if(recv(new_fd,open2,15,0)==-1)
continue;
else
if(strcmp(open2,"open")==0)
printf("open :%s\n",open2);
if(send(new_fd,sen_uname,strlen(sen_uname),0)==-1)
perror("send username:");
exit(-1);
if(recv(new_fd,logg_name,32,0)==-1)
exit(-1);
if(send(new_fd,sen_up,strlen(sen_up),0)==-1)
{
perror("error in sending password");
exit(-1);
if(recv(new_fd,pass_word,32,0)==-1)
exit(-1);
else
if(send(new_fd,open3,12,0)==-1)
exit(-1);
continue;
for(i=0;i<4;i++)
if(strcmp(log[i].logg,logg_name)==0)
if(strcmp(log[i].pass,pass_word)==0)
{
printf("\nmy_protocol>Loggin sucessfully\n");
if(send(new_fd,sen_uacck,strlen(sen_uacck),0)==-1)
exit(-1);
break;
else
printf("\nmy_protocol>Invalid password\n");
memset(sen_uacck1,0,10);
strcpy(sen_uacck1,"Invalid");
send(new_fd,sen_uacck1,strlen(sen_uacck1),0);
break;
else
if(i==3)
printf("\nmy_protocol>Invalid password\n");
send(new_fd,"Invalid",8,0);
break;
}
++flag;
if((new_data_fd=accept(sockfd_data,(struct sockaddr*)&data_addr,&sin_size))==-1)
perror("new_data_fd accept");
//continue;
printf("new_data_fd = %d\n",new_data_fd);
if(!fork())
{ // in child
memset(servbuf,0,MAX);
memset(comr1,0,20);
if(fork()==0)
printf("inner while\n");
pol=recv(new_fd,comr1,MAX,0) ;
printf("\n%s",comr1);
if(pol==-1)
perror("****receive comr1");
close(sockfd_cmd);
//close(new_fd);
exit(0);
else
remove("pro1");
// close(new_fd);
// close(sockfd_data);
//close(sockfd_cmd);
continue;
// break;
}
if(strcmp("help",comr1)==0)
memset(help_buff,0,200);
ffd1 = fopen("help","r");
if(ffd1==NULL)
perror("---------open pro1");
exit(-1);
else
if(fread(help_buff,1,200,ffd1)<0)
exit(-1);
if(send(new_data_fd,help_buff,strlen(help_buff),0)==-1)
exit(-1);
close(ffd1);
}
//***************************************************************************
*************
put_serv(new_fd ,new_data_fd );
continue;
} // if put ends
get_serv(new_fd,new_data_fd);
continue;
} // if get ends
//***************************************************************************
*************
ffd = open("pro1",O_WRONLY|O_CREAT,0666);
if(ffd== -1)
perror("---------open pro1");
exit(-1);
comr[0] = comr1;
fflush(stdout);
close(1);
dup(ffd);
execvp(comr[0],comr);
// close(ffd);
} // else of if receive
wait(0);
close(ffd);
filefd = fopen("pro1","r");
if((recvedb=fread (servbuf,1,800,filefd))==-1)
exit(1);
perror("send error");
exit(-1);
remove("pro1");
close(filefd);
} // 2nd while1
while(waitpid(-1,NULL,WNOHANG)>0);
} //end of 1st fork
return 0;
} // main ends
//**********************************************************************
char put_buff_file[1000];
char put_file_name[32];
FILE* put_fd;
int len,f_write;
int file_fd;
memset(put_buff_file,0,1000);
if(send(new_fd,put_buff,30,0)==-1)
send(new_fd,put_buff_err,40,0);
else
if(recv(new_fd,put_file_name,32,0)==-1)
{
perror("****file receive error:");
else
if(recv(new_data_fd,put_buff_file,1000,0)==-1)
if((file_fd=open(put_file_name,O_CREAT|O_RDWR,0666))==-1)
perror("error in open:");
exit(-1);
else
len = strlen(put_buff_file);
if(write(file_fd,put_buff_file,len)==-1)
exit(-1);
close(put_fd);
close(file_fd);
}
}
return 0;
//..................................................................
// end of put_serv
//.................................................................
char get_file_name[32];
int name_read;
memset(get_buff_file,0,1000);
memset(get_file_name,0,32);
send(new_fd, get_buff_err,40,0);
else
{
if(recv(new_fd,get_file_name,32,0)==-1)
send(new_fd,get_buff,30,0);
if( recv(new_fd,get_file_name,32,0)==-1)
exit(-1);
else
get_fd = fopen(get_file_name,"r");
if(get_fd ==NULL)
exit(-1);
else
name_read=fread(get_buff_file,1,1000,get_fd);
if(name_read==0)
exit(-1);
}
if((send(new_data_fd,get_buff_file,name_read,0))==-1)
exit(-1);
return 0;
//**********************************************************************
//server ends
CLIENT CODE
//client
#include<stdio.h>
#include<cpio.h>
#include<errno.h>
#include<sys/types.h>
#include<netinet/in.h>
#include<sys/socket.h>
#include<string.h>
#include<fcntl.h>
//;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
//fun
//;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
int mych,swno,stat;
char mycho,sw[4]={"OFF","OFF","OFF","OFF"};
int put_client(int,int);
int get_client(int,int);
int length;
void status(void)
{
printf("\nCurrent Status:");
printf("\nSW1 :%s",sw[0]);
printf("\nSW2 :%s",sw[1]);
printf("\nSW3 :%s",sw[2]);
printf("\nSW4 :%s",sw[3]);
void getstatus(void)
scanf("%d",&swno);
scanf("%d",&stat);
if(stat==0)
strcpy(mycho,"OFF");
else
strcpy(mycho,"ON");
if((swno==1)&&(stat==0))
send(sockfd_cmd,"SW1 : OFF",10,0);
else if((swno==1)&&(stat==1))
send(sockfd_cmd,"SW1 : ON",9,0);
else if((swno==2)&&(stat==0))
send(sockfd_cmd,"SW2 : OFF",10,0);
else if((swno==2)&&(stat==1))
send(sockfd_cmd,"SW2 : ON",9,0);
else if((swno==3)&&(stat==0))
send(sockfd_cmd,"SW3 : OFF",10,0);
else if((swno==3)&&(stat==1))
send(sockfd_cmd,"SW3 : ON",9,0);
else if((swno==4)&&(stat==0))
send(sockfd_cmd,"SW4 : OFF",10,0);
else if((swno==4)&&(stat==1))
send(sockfd_cmd,"SW4 : ON",9,0);
switch(swno)
case 1: strcpy(sw[0],mycho);
break;
case 2: strcpy(sw[1],mycho);
break;
case 3: strcpy(sw[2],mycho);
break;
case 4: strcpy(sw[3],mycho);
break;
char com[20],ch;
char buf[MAXDATASIZE],buf1[MAXDATASIZE];
char rec_uname[32];
char rec_upass[32];
char user_name[32];
char pass_word[32];
char rec_acck[32];
char *pass_word1;
char open1[15];
int len;
int i;
int flag=0;
//**************************************************
//**************************************************
if((sockfd_cmd=socket(AF_INET,SOCK_STREAM,0))==-1)
perror("control socket");
exit(1);
their_addr.sin_family=AF_INET;
their_addr.sin_port=htons(PORT);
bzero(&(their_addr.sin_zero),8);
if((sockfd_data=socket(AF_INET,SOCK_STREAM,0))==-1)
exit(1);
data_addr.sin_family = AF_INET;
data_addr.sin_port = htons(DATAPORT);
// data_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
data_addr.sin_addr.s_addr = inet_addr(argv[1]);
bzero(&(data_addr.sin_zero),8);
//;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
printf("connecting to server.........\n");
exit(1);
///////////////////////////////////////////////////////////////////
if(flag==0)
memset(user_name,0,32);
memset(pass_word,0,32);
memset(rec_uname,0,32);
memset(rec_upass,0,32);
memset(rec_acck,0,32);
printf("my_protocol");
scanf("%s",open1);
if(send(sockfd_cmd,open1,15,0)==-1)
exit(-1);
if(recv(sockfd_cmd,rec_uname,20,0)==-1)
printf("%s\n",rec_uname);
scanf("%s",user_name);
if(send(sockfd_cmd,user_name,strlen(user_name),0)==-1)
exit(-1);
if(recv(sockfd_cmd,rec_upass,30,0)==-1)
exit(-1);
pass_word1=(char *)getpass("password");
strcpy(pass_word,pass_word1);
if(send(sockfd_cmd,pass_word,strlen(pass_word),0)==-1)
exit(-1);
if(recv(sockfd_cmd,rec_acck,15,0)==-1)
{
perror("my_protocol>error in reciving acck") ;
exit(-1);
printf("acck is:%s--\n",rec_acck);
if(strcmp(rec_acck,"sucess")==0)
printf("acck is:%s\n",rec_acck);
else
printf("\nmy_protocol>loggin failed");
close(sockfd_data);
close(sockfd_cmd);
exit(-1);
} // if flag = 0 ends
////////////////////////////////////////////////////////////////////
exit(1);
while(1)
{
printf("Enter your choise:\n1. For Command\n2. For Switching\n");
if(mych==1)
memset(buf,0,800);
memset(com,0,20);
len =strlen(com);
com[len]='\0';
//..................................................................... ..
if(strcmp("put",com)==0)
if(send(sockfd_cmd,com,len+1,0)==-1)
exit(-1);
put_client(sockfd_cmd,sockfd_data);
continue;
if(strcmp("get",com)==0)
if(send(sockfd_cmd,com,len+1,0)==-1)
{
perror("send get error:");
exit(-1);
get_client(sockfd_cmd,sockfd_data);
continue;
//............................................. .....................
printf("client exiting\n");
if(send(sockfd_cmd,com,len+1,0)==-1)
perror("send bye:");
exit(-1);
wait(0);
close(sockfd_cmd);
close(sockfd_data);
remove("pro1");
exit(0);
//break;
if(strcmp("help",com)==0)
memset(buf1,0,800);
if(send(sockfd_cmd,com,len+1,0)==-1)
exit(-1);
else
if((numbytes1=recv(sockfd_data,buf1,MAXDATASIZE,0))==-1)
exit(1);
else
buf1[numbytes1]='\0';
printf("Received: %s\n",buf1);
continue;
} // help ends
if(send(sockfd_cmd,com,len+1,0)==-1)
perror("send com");
exit(-1);
if((numbytes=recv(sockfd_data,buf,MAXDATASIZE,0))==-1)
exit(1);
else
buf[numbytes]='\0';
printf("Received: %s\n",buf);
else
status();
getstatus();
status();
} // while closes
return(0);
} // main closes
//.................................................................
////////////main ends//////////////////////////////////////////////
//.................................................................
char file_name[32];
char rec_buff[30];
char send_buff[1000];
int put_fd;
memset(file_name,0,32);
memset(rec_buff,0,30);
memset(send_buff,0,1000);
if(recv(sockfd_cmd,rec_buff,30,0)==-1)
exit(1);
else
printf("%s\n",rec_buff);
file_name[strlen(file_name)+1]='\0';
if(send(sockfd_cmd,file_name,strlen(file_name),0)==-1)
exit(-1);
}
if((put_fd=open(file_name,O_RDONLY,0666))<=0)
printf("%s",file_name);
exit(-1);
else
read(put_fd,send_buff,1000,0);
if(send(sockfd_data,send_buff,strlen(send_buff),0)==-1)
perror("error:sending file");
exit(-1);
return (0);
//..................................................................
// get_client starts
//................................................................
int get_client(int sockfd_cmd,int sockfd_data)
char file_name[32];
char rec_buff[30];
char recv_buff[1000];
int get_fd;
memset(file_name,0,32);
memset(rec_buff,0,30);
memset(recv_buff,0,1000);
if(recv(sockfd_cmd,rec_buff,30,0)==-1)
exit(1);
else
printf("%s\n",rec_buff);
file_name[strlen(file_name)+1]='\0';
if(send(sockfd_cmd,file_name,32,0)==-1)
exit(-1);
if(recv(sockfd_data,recv_buff,1000,0)==-1)
{
exit(-1);
if((get_fd=open(file_name,O_CREAT|O_WRONLY,0666))<=0)
printf("%s",file_name);
exit(-1);
else
write(get_fd,recv_buff,strlen(recv_buff),0);
return 0;
//...........................................
// client ends//.........................................................
CONCLUSION
On the successful completion of the project we conclude that the socket API’s can be
used for communication over a network in Linux. As far as future enhancement is
concerned this tool can be equipped with graphical user interface and Transfer of data
in different formats. If the above future enhancements are included then it will give us
a user friendly and secured data transfer tool over a network.