EmbLogic's Blog

Inter Process Communication using MESSAGE QUEUES.

IPC USING MESSAGE QUEUES

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
included stdio.h, sys/msg.h, stdlib.h, sys/types.h, unistd.h, sys/ipc.h.
—————————-
revision 1.1
date: 2014/08/28 04:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: server.c,v
Working file: server.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
this is the server program.
it creates a message queue and waits to recieve data on it from a requesting client.
multiple fork calls are made according to the number of requesting client
each child of the server deals with respective client and sychronisation chived by the type field given in each message queue structure.
then the server sends a processing requst to the processing client.
once the processing client returns the result on a seperate message queue, the server puts the result back on the respective client message queue.
each client then picks up the message according to the type specified, which in turn is their own pid(process id).
—————————-
revision 1.1
date: 2014/08/28 04:54:05;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: client.c,v
Working file: client.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the requesting client program.
It sends a request on the message queue created by the server.
and waits for the processed result.
picks up the message of its own type only.
here tpre is the pid of client.
—————————-
revision 1.1
date: 2014/08/28 05:05:52;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: process.c,v
Working file: process.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the processing client.
it performs the calculations on request from the server.
and returns the answer in a message queue created by the server.
with a particular type attached to the mesage.
—————————-
revision 1.1
date: 2014/08/28 05:08:33;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

Server rcs ( TCP, AF_UNIX)

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.2
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 2; selected revisions: 2
11 description:
12 Implementation of server.
13 Protocol : TCP
14 Domain : AF_UNIX
15 —————————-
16 revision 1.2
17 date: 2014/08/25 05:19:58; author: root; state: Exp; lines: +10 -10
18 Server successfully implemented.
19 Server accepts requests and sends responses.
20 —————————-
21 revision 1.1
22 date: 2014/08/25 05:03:27; author: root; state: Exp;
23 Initial revision
24 =============================================================================
~
~
~
~
~
~
~
~
~
~
“logfile” 24L, 629C 1,0-1 All

Posted in Uncategorized | Leave a comment

Server rcs ( UDP, AF_UNIX)

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.2
5 branch:
6 locks: strict
7 root: 1.2
8 access list:
9 symbolic names:
10 keyword substitution: kv
11 total revisions: 2; selected revisions: 2
12 description:
13 implemented sockets for datagram under af_unix domain.
14 Works ok, but I have some queries.
15 Queries :
16 If more than one request come, then server’s sendto call returns bad file descriptor with each request it servers, but th e messages are exchanged properly
17 The server socket fd and the client socket fd are same, how come ?
18 —————————-
19 revision 1.2 locked by: root;
20 date: 2014/08/25 05:42:35; author: root; state: Exp; lines: +0 -6
21 Server successfully serves more than 1 client, but not simultaneoulsy, needs multithreading
22 —————————-
23 revision 1.1
24 date: 2014/08/22 20:27:03; author: root; state: Exp;
25 Initial revision
26 =============================================================================
~
~
~
~
~
~
~
1 line less; before #1 2 seconds ago 1,0-1 All

Posted in Uncategorized | Leave a comment

Server Implementation ( UDP , AF_INET)

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.2
5 branch:
6 locks: strict
7 root: 1.2
8 access list:
9 symbolic names:
10 keyword substitution: kv
11 total revisions: 2; selected revisions: 2
12 description:
13 Implementation fo server.
14 Protocol : UDP
15 Domain : AF_INET
16 —————————-
17 revision 1.2 locked by: root;
18 date: 2014/08/25 05:13:38; author: root; state: Exp; lines: +1 -0
19 Server is able to accpet client requests and send them response.
20 Server serves one client at a time.
21 —————————-
22 revision 1.1
23 date: 2014/08/25 05:07:54; author: root; state: Exp;
24 Initial revision
25 =============================================================================
~
~
~
~
~
~
~
~
~
“logfile” 25L, 678C 1,0-1 All

Posted in Uncategorized | Leave a comment

Socket Programming : ( Server Implementation for TCP under AF_INET domain )

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.2
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 2; selected revisions: 2
11 description:
12 Implementation of server for stream socket ( TCP ) under AF_INET domain.
13 —————————-
14 revision 1.2
15 date: 2014/08/25 04:55:04; author: root; state: Exp; lines: +1 -0
16 Server successfully implemented.
17 —————————-
18 revision 1.1
19 date: 2014/08/25 04:53:24; author: root; state: Exp;
20 Initial revision
21 =============================================================================
~
~
~
~
~
~
~
~
~
~
~
~
~
“logfile” 21L, 595C 1,0-1 All

Posted in Uncategorized | Leave a comment

enter 5 number find largest and lowest number

RCS file: 4.2.c,v
Working file: 4.2.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
enter the 5 number and find largest and smallest number
—————————-
revision 1.1
date: 2014/08/24 06:33:38; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

Client Server communication -IPC ( using message queue )

header file ———————————-

 
RCS file: ./header.h,v
Working file: ./header.h
head: 1.5
branch:
locks: strict
root: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
—————————-
revision 1.5 locked by: root;
date: 2014/08/23 08:22:06; author: root; state: Exp; lines: +2 -0
gave pid to struct data member.
—————————-
revision 1.4
date: 2014/08/17 10:33:23; author: root; state: Exp; lines: +1 -0
add result to struct data members.
—————————-
revision 1.3
date: 2014/08/17 09:36:55; author: root; state: Exp; lines: +1 -1
implemented fork().
—————————-
revision 1.2
date: 2014/08/16 06:15:00; author: root; state: Exp; lines: +3 -3
declared header files for server.
declared structure for data & msg queue.
—————————-
revision 1.1
date: 2014/08/16 06:08:32; author: root; state: Exp;
Initial revision
=============================================================================

server ————————————-

 
RCS file: ./server.c,v
Working file: ./server.c
head: 1.24
branch:
locks: strict
root: 1.24
access list:
symbolic names:
keyword substitution: kv
total revisions: 24; selected revisions: 24
description:
—————————-
revision 1.24 locked by: root;
date: 2014/08/23 08:05:07; author: root; state: Exp; lines: +3 -3
………………
—————————-
revision 1.23
date: 2014/08/23 07:59:40; author: root; state: Exp; lines: +21 -9
made msgsnd afterr1.mtype
run processing clients in backg & while(1).
completed using 3 clients.
—————————-
revision 1.22
date: 2014/08/23 05:01:22; author: root; state: Exp; lines: +3 -3
completed
—————————-
revision 1.21
date: 2014/08/22 16:41:30; author: root; state: Exp; lines: +9 -4
gave pid member to struct data.
assigned to mtype 1 for +,2 for -,3 for *.
assigned vale of pid to mtype after received from processing client.
—————————-
revision 1.20
date: 2014/08/20 04:29:05; author: root; state: Exp; lines: +1 -1
implemented fork for creating three child.
—————————-
revision 1.19
date: 2014/08/20 04:21:38; author: root; state: Exp; lines: +1 -1
created two child.
—————————-
revision 1.18
date: 2014/08/20 04:05:42; author: root; state: Exp; lines: +3 -3
run processing clients in background.
—————————-
revision 1.17
date: 2014/08/17 13:17:36; author: root; state: Exp; lines: +40 -37
made whole process in while loop.
—————————-
revision 1.16
date: 2014/08/17 11:57:36; author: root; state: Exp; lines: +11 -0
implemented msgsnd() for sending struct msg to resultant client.
—————————-
revision 1.15
date: 2014/08/17 11:25:31; author: root; state: Exp; lines: +1 -1
. .
—————————-
revision 1.14
date: 2014/08/17 11:23:04; author: root; state: Exp; lines: +9 -7
implemented msgrcv() for receiving struct msg from msg_queue4.
—————————-
revision 1.13
date: 2014/08/17 11:15:37; author: root; state: Exp; lines: +9 -0
\made system call according to operator from client.
—————————-
revision 1.12
date: 2014/08/17 11:07:29; author: root; state: Exp; lines: +1 -1
declared id2.
—————————-
revision 1.11
date: 2014/08/17 11:06:55; author: root; state: Exp; lines: +4 -4
*** empty log message ***
—————————-
revision 1.10
date: 2014/08/17 11:05:20; author: root; state: Exp; lines: +25 -14
changed msgqueue id’s name.
wrote struct msg to msgqueue3.
—————————-
revision 1.9
date: 2014/08/17 10:13:46; author: root; state: Exp; lines: +1 -1
changed msgtyp in msgrcv() to 0.
—————————-
revision 1.8
date: 2014/08/17 09:43:09; author: root; state: Exp; lines: +3 -3
changed struct msg member name b to d.
—————————-
revision 1.7
date: 2014/08/17 09:41:06; author: root; state: Exp; lines: +6 -1
used system call msgrcv for receiving msg from msg_queue1.
—————————-
revision 1.6
date: 2014/08/17 09:38:01; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.5
date: 2014/08/17 09:37:18; author: root; state: Exp; lines: +13 -1
implemented fork().
—————————-
revision 1.4
date: 2014/08/16 07:00:17; author: root; state: Exp; lines: +3 -3
*** empty log message ***
—————————-
revision 1.3
date: 2014/08/16 06:54:17; author: root; state: Exp; lines: +7 -3
checked msg queue id for msg_queue1.
changed key for queue1,queue2,queue3,queue4.
printed msg_queue id for all queues.
—————————-
revision 1.2
date: 2014/08/16 06:24:53; author: root; state: Exp; lines: +19 -1
contain basic program for server
craeted four msg queues.
—————————-
revision 1.1
date: 2014/08/16 06:08:47; author: root; state: Exp;
Initial revision
=============================================================================

client  ————————————–

 
RCS file: ./client1.c,v
Working file: ./client1.c
head: 1.22
branch:
locks: strict
root: 1.22
access list:
symbolic names:
keyword substitution: kv
total revisions: 22; selected revisions: 22
description:
contain basic program for client1
created queue for transmitting msg from client1 to server.
—————————-
revision 1.22 locked by: root;
date: 2014/08/22 16:50:42; author: root; state: Exp; lines: +1 -0
*** empty log message ***
—————————-
revision 1.21
date: 2014/08/22 16:46:15; author: root; state: Exp; lines: +1 -1
assigned pid to member pid.
—————————-
revision 1.20
date: 2014/08/20 04:41:00; author: root; state: Exp; lines: +1 -1
improved result statement.
—————————-
revision 1.19
date: 2014/08/20 04:18:36; author: root; state: Exp; lines: +1 -1
..
—————————-
revision 1.18
date: 2014/08/18 04:55:16; author: root; state: Exp; lines: +2 -20
*** empty log message ***
—————————-
revision 1.17
date: 2014/08/18 04:39:10; author: root; state: Exp; lines: +4 -0
implemented system call msgctl() to remove created msgqueue’s.
—————————-
revision 1.16
date: 2014/08/18 04:37:36; author: root; state: Exp; lines: +2 -2
..
—————————-
revision 1.15
date: 2014/08/18 04:36:14; author: root; state: Exp; lines: +18 -4
implemented msgget() for msgq 3 & 4.
—————————-
revision 1.14
date: 2014/08/17 12:54:25; author: root; state: Exp; lines: +1 -1
changed msgflag in msgget() for msq1.
—————————-
revision 1.13
date: 2014/08/17 12:10:13; author: root; state: Exp; lines: +1 -1
changed arg 2 of msgsnd.
—————————-
revision 1.12
date: 2014/08/17 12:08:18; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.11
date: 2014/08/17 12:05:20; author: root; state: Exp; lines: +14 -2
modified msgrcv().
created msg_queue2.
—————————-
revision 1.10
date: 2014/08/17 12:01:52; author: root; state: Exp; lines: +3 -1
implemented msgrcv() for receiving result from server.
—————————-
revision 1.9
date: 2014/08/17 11:44:57; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.8
date: 2014/08/17 11:44:09; author: root; state: Exp; lines: +2 -2
..
—————————-
revision 1.7
date: 2014/08/17 11:42:25; author: root; state: Exp; lines: +5 -5
entered user data using command line.
—————————-
revision 1.6
date: 2014/08/17 09:24:43; author: root; state: Exp; lines: +7 -2
implemented system call msgsnd().]
—————————-
revision 1.5
date: 2014/08/16 07:23:57; author: root; state: Exp; lines: +1 -1
modified arg 2 of msgsnd.
—————————-
revision 1.4
date: 2014/08/16 07:21:03; author: root; state: Exp; lines: +7 -6
gave system call() msgsnd().
—————————-
revision 1.3
date: 2014/08/16 07:17:07; author: root; state: Exp; lines: +5 -0
gave user data in structure msg.
—————————-
revision 1.2
date: 2014/08/16 07:00:55; author: root; state: Exp; lines: +1 -0
printmsg_queue1 id.
—————————-
revision 1.1
date: 2014/08/16 06:49:46; author: root; state: Exp;
Initial revision
=============================================================================

addition ——————————————-

 
RCS file: ./add.c,v
Working file: ./add.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
implemented program code for addition.
—————————-
revision 1.1 locked by: root;
date: 2014/08/23 16:38:40; author: root; state: Exp;
Initial revision
=============================================================================

subtraction —————————————-

 
RCS file: ./subb.c,v
Working file: ./subb.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
implemented program code for subtraction.
—————————-
revision 1.1 locked by: root;
date: 2014/08/23 16:39:37; author: root; state: Exp;
Initial revision
=============================================================================

multipication —————————————–

 
RCS file: ./mul.c,v
Working file: ./mul.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
implemented program code for multipocation.
—————————-
revision 1.1 locked by: root;
date: 2014/08/23 16:40:23; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

Parallel port modes
The IEEE 1284 Standard which has been published in 1994 defines five modes of data transfer for parallel port. They are,

1) Compatibility Mode
2) Nibble Mode
3) Byte Mode
4) EPP
5) ECP

Hardware
The pin outs of DB25 connector is shown in the picture below
Parallel Port

The lines in DB25 connector are divided in to three groups, they are

1) Data lines (data bus)
2) Control lines
3) Status lines

As the name refers , data is transferred over data lines , Control lines are used to control the peripheral and of course , the peripheral returns status signals back computer through Status lines. These lines are connected to Data, Control And Status registers internally . The details of parallel port signal lines are given below
Pin No (DB25) Signal name Direction Register – bit Inverted
1 nStrobe Out Control-0 Yes
2 Data0 In/Out Data-0 No
3 Data1 In/Out Data-1 No
4 Data2 In/Out Data-2 No
5 Data3 In/Out Data-3 No
6 Data4 In/Out Data-4 No
7 Data5 In/Out Data-5 No
8 Data6 In/Out Data-6 No
9 Data7 In/Out Data-7 No
10 nAck In Status-6 No
11 Busy In Status-7 Yes
12 Paper-Out In Status-5 No
13 Select In Status-4 No
14 Linefeed Out Control-1 Yes
15 nError In Status-3 No
16 nInitialize Out Control-2 No
17 nSelect-Printer OutControl-3 Yes
18-25 Ground - - -

Parallel port registers
As you know, the Data, Control and status lines are connected to there corresponding registers inside the computer. So by manipulating these registers in program , one can easily read or write to parallel port with programming languages like ‘C’ and BASIC.

The registers found in standard parallel port are ,

1) data register
2) Status register
3) Control register

As there names specifies, Data register is connected to Data lines, Control register is connected to control lines and Status register is connected to Status lines. (Here the word connection does not mean that there is some physical connection between data/control/status lines. The registers are virtually connected to the corresponding lines.). So what ever you write to these registers , will appear in corresponding lines as voltages, Of course, you can measure it with a multimeter. And What ever you give to Parallel port as voltages can be read from these registers(with some restrictions). For example , if we write ’1′ to Data register , the line Data0 will be driven to +5v. Just like this ,we can programmatically turn on and off any of the data lines and Control lines.

Posted in Uncategorized | Leave a comment

program to find sum of two numbers without using operator

RCS file: 1.c,v
Working file: 1.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: root;
date: 2014/08/19 12:34:16; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

A chat client ( to chat between two terminals) : Source code snippet

ret_msnd = msgsnd(ret_mget, &m_p, sizeof(struct content), 0);
89 if(strcmp(m_p.con.msg, “exit”) == 10)
90 {
91 printf(“Client 1 says bye\n”);
92 kill(pid, SIGINT); /* kill the child generated for reading the inbox, before parent goe s off */
93 exit(EXIT_SUCCESS);
94 }
95 if(ret_msnd == -1) /* msgsnd fails then kill the child , and the parent.*/
96 {
97 printf(“Failed to send message to write q\n”);
98 perror(“msgsnd”);
99 kill(pid, SIGINT);
100 exit(EXIT_FAILURE);
101 }

Posted in Uncategorized | Leave a comment

difference b/w printf ,fprintf,snprintf and sprintf

printf, fprintf, sprintf, snprintf

Defined in header <stdio.h>
(1)
?int printf( const char          *format, … );?
 
?int printf( const char *restrict format, … );?
 
(2)
int fprintf( FILE          *stream, const char          *format, … );
 
int fprintf( FILE *restrict stream, const char *restrict format, … );
 
(3)
int sprintf( char          *buffer, const char          *format, … );
int sprintf( char *restrict buffer, const char *restrict format, … );
 
int snprintf( char *restrict buffer, int buf_size,
const char *restrict format, … );
(4)  

Loads the data from the given locations, converts them to character string equivalents and writes the results to a variety of sinks.

1) Writes the results to stdout.
2) Writes the results to a file stream stream.
3) Writes the results to a character string buffer.
4) Writes the results to a character string buffer. At most buf_size – 1 characters are written. The resulting character string will be terminated with a null character, unless buf_size is zero.
Posted in Uncategorized | Leave a comment

IPC USING FIFOS AND SEMAPHORES

******************************************************************************************

RCS file: server.c,v
Working file: server.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
Made a server file which takes request from client and forwards it to processing client
Then it takes result from processing client and gives the result back to the requesting client
the requesting client is given a pid to which server returns his answer.
=============================================================================

RCS file: script,v
Working file: script
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is the script file which is made to execute all the files at once.
total 5 fifos are used and one semaphore is used in the server.
=============================================================================

RCS file: client.c,v
Working file: client.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
The client sends the request using command line arguments
and at the finishing end it reads the result back from the server.
=============================================================================

RCS file: add.c,v
Working file: add.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
processing client adds the two files after reading values from server
and writes back the result to the server
=============================================================================

RCS file: sub.c,v
Working file: sub.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
thats another processing client
it subtracts the two values
=============================================================================

RCS file: mul.c,v
Working file: mul.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
its function is also same as other processing clients but it multiplies them.
=============================================================================

Posted in Uncategorized | Leave a comment

Character Driver VS Block Driver

There are two main types of devices under all systems, character and block devices. Character devices are those for which no buffering is performed, and block devices are those which are accessed through a cache. Block devices must be random access, but character devices are not required to be, though some are. Filesystems can only be mounted if they are on block devices.

Character devices are read from and written to with two function: foo_read() and foo_write(). The read() and write() calls do not return until the operation is complete. By contrast, block devices do not even implement the read() and write() functions, and instead have a function which has historically been called the “strategy routine.” Reads and writes are done through the buffer cache mechanism by the generic functions bread(), breada(), and bwrite(). These functions go through the buffer cache, and so may or may not actually call the strategy routine, depending on whether or not the block requested is in the buffer cache (for reads) or on whether or not the buffer cache is full (for writes).

A request may be asyncronous: breada() can request the strategy routine to schedule reads that have not been asked for, and to do it asyncronously, in the background, in the hopes that they will be needed later.

The sources for character devices are kept in …/kernel/chr_drv/, and the sources for block devices are kept in …/kernel/blk_drv/. They have similar interfaces, and are very much alike, except for reading and writing. Because of the difference in reading and writing, initialization is different, as block devices have to register a strategy routine, which is registered in a different way than the foo_read() and foo_write()routines of a character device driver.

Posted in Device Drivers | Leave a comment

IPC USING FIFOS AND SEMAPHORES.

HEADER FILE ***************************************************************

RCS file: ./header.h,v
Working file: ./header.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Included “stdio.h” , “stdlib.h”, “unistd.h”, “linux/sem.h”, “fcntl.h”, and “signal.h”.
Declaration of the structure “package”, with members – op1(int), op2(int), arth(char), pid(pid_t), result(int).
—————————-
revision 1.1
date: 2014/08/12 10:59:58;  author: root;  state: Exp;
Initial revision
=============================================================================

SERVER PROGRAM **************************************************************

RCS file: ./server.c,v
Working file: ./server.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the server program .
Declared 3 fifos , 1 for client routines and 2 for processing routines.
fork children of the server. number of children is equal to number of clients.
Each child links with respective clients and reads the data to be processed.
then the forked child send the data to the processing client .
gets the result back, and sends it to the client.
semaphores are used wherever fifos are shared.
—————————-
revision 1.1
date: 2014/08/12 11:18:11;  author: root;  state: Exp;
Initial revision
=============================================================================

CLIENT PROGRAM **************************************************************

RCS file: ./client.c,v
Working file: ./client.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the client program.
It writes the values to b written into the fifo for server to read it.
this it pauses using pause() system call.
when the server has the answer it prompts the client by sending it a signal using kill system call.
the respective client whose pid is present in the kill() is resumed , reads the result and displays it.
—————————-
revision 1.1
date: 2014/08/12 11:21:10;  author: root;  state: Exp;
Initial revision
=============================================================================

ADD PROCESSING CLIENT *******************************************************

RCS file: ./add.c,v
Working file: ./add.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the addition processing client.
it reads the values from server using one fifo.
each processing client is using a common fifo to write back the result to server.
—————————-
revision 1.1
date: 2014/08/12 11:23:54;  author: root;  state: Exp;
Initial revision
=============================================================================

SUBTRACT PROCESSING CLIENT **************************************************

RCS file: ./subtract.c,v
Working file: ./subtract.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the subtracting client.
it reads the values from server using one fifo.
each processing client is using a common fifo to write back the result to server.
—————————-

Posted in Uncategorized | Leave a comment

IPC (Using FIFOS , without semaphores)

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.5
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 5; selected revisions: 5
11 description:
12 Implementing ipc using fifos
13 —————————-
14 revision 1.5
15 date: 2014/08/12 05:37:54; author: root; state: Exp; lines: +13 -4
16 Completed the implementation the IPC(client-server) using FIFOS.
17 No synchronisation mechanism used.
18 Issues :
19 If more than one client send the same type of request, then the server becomes less reliable
20 —————————-
21 revision 1.4
22 date: 2014/08/10 18:08:52; author: root; state: Exp; lines: +4 -0
23 Upto here :
24 1. the req client 1 successfully write the structure into the fifo, which is successfully read by the server, and displayed.
25 2. the structure read by the server is now to be written in the fifo of the processing client.
26 3. next target : to successfully write the structure to the fifo of pc.
27 —————————-
28 revision 1.3
29 date: 2014/08/10 18:00:40; author: root; state: Exp; lines: +77 -17
30 Trying to read the req fifo of a client by the server.
31 —————————-
32 revision 1.2
33 date: 2014/08/10 16:45:36; author: root; state: Exp; lines: +1 -1
34 Implemented _create_fifos() function that enables the server to create child readers for reading each of the request fifos.
“log_file” 39L, 1544C 1,0-1 Top

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment