EmbLogic's Blog

socket using AF_INET

RCS file: server_inet.c,v
Working file: server_inet.c
head: 1.8
branch:
locks: strict
root: 1.8
access list:
symbolic names:
keyword substitution: kv
total revisions: 8; selected revisions: 8
description:
this the file for srver
—————————-
revision 1.8 locked by: root;
date: 2015/04/11 06:49:58; author: root; state: Exp; lines: +1 -1
here now,performing the reading
—————————-
revision 1.7
date: 2015/04/11 06:47:43; author: root; state: Exp; lines: +1 -1
here givingf the accept(),so that a particular socket can be created for processing the particular req from the client side
this call will creat the socket that would connect to that particular req
—————————-
revision 1.6
date: 2015/04/11 06:45:31; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.5
date: 2015/04/11 06:44:31; author: root; state: Exp; lines: +2 -2
giving the listen(),so that the reaquest from the side of the client can be listed in the list queue
—————————-
revision 1.4
date: 2015/04/11 06:42:56; author: root; state: Exp; lines: +2 -2
giving the socket call
so that a socket will be created which will return a socket fd
giving the bind call,which will give the name to the socket which we have been created,
so the socket created here will be the named socket
—————————-
revision 1.3
date: 2015/04/11 06:42:15; author: root; state: Exp; lines: +1 -1
defining the structure variables sin.family,port and addr
—————————-
revision 1.2
date: 2015/04/11 06:40:39; author: root; state: Exp; lines: +1 -1
included the header files
defining the variables
—————————-
revision 1.1
date: 2015/04/11 06:39:30; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Project 04: FTP based Client Server using Threads and Sockets | Leave a comment

structures

structure is a user defined data type available in c programming,it allows us to combine data items of different kinds and helps us to construct a complex data type in a meaningful way.

Structure is used to represent a record. Suppose we want to keep track of books in a library. For this we have to track some attributed(title,author,subject,book id) of each book. To define a structure we must use the struct statement. This statement defines a new data type with more then one member for our program . the format for struct statement is :

struct [structure tag]

{

member definition;

member definition;

….

}[one or more structure variables];

the structure tag and structure variable is optional and each member definition is a normal variable definition such as int i; or float j or any other variable definition we can also declare structure variable separately like:

struct structure tag structure variable1,structure variable2… ;

a structure member has no meaning on its own so we cannot access it directly. In order to access a structure member,the member name must be linked with the structure variable using dot (.)operator also called period or member access operator .we can also use structure pointer operator if we are declaring a pointer variable for that structure .

Structures can also be nested within other structure in C programming and they can also be passed as a function argument like any other variable.

Bit fields:-

bit fields allow the packing of data in a structure. This is specially useful when memory is limited . Suppose our structure contains some true/false variables then we are going to store either 0 or 1 in these variables. so C programming offers us a better way to utilize the memory space in these situations . We can define the width of variable which tells the C compiler that we are going to use only those number of bits for example :

struct

{

unsigned int cgpa : 3;

}student;

the above structure definition instructs C compiler that cgpa variable is going to use only

3 bits to store the value,if we try to use more then 3 bits then it will not allow us to do so.

Posted in Uncategorized | Leave a comment

Pointers

Pointers

Pointers are just variables like any other variables we declare, the only difference is that, the so called normal variables store some sort of data like an integer,a character,a floating point number, on the other hand a pointer stores a logical address belonging to the data or stack segment (at which some data is stored or is to be stored).

A pointer provides us the ability to access and modify data from anywhere. Pointers allow faster access to memory.

Pointer declaration:

The ‘*’ operator is used to declare a pointer for e.g. int *ptr or char *ptr

In the former case ptr is a pointer which would hold the memory location of an integer similarly in the latter ptr is a pointer which would store the memory location of a character. Its important to note that the datatype preceding the identifier is not the datatype of the identifier its the datatype of the value that would be stored or is already present at the location ptr is pointing to.

Pointer Initialization:

Its important to remember that a pointer when declared does not store a valid logical address, rather it holds a garbage value and such pointers are called wild pointers and are very dangerous as they may be pointing to a location where some data is already stored and you might end up overwriting it. So its essential to give a valid address to the pointer (You shouldn’t worry too much about this as the compiler would give you a segmentation fault at run time if you try to access a wild pointer, but its a good habit to initialize the pointer as soon as you declare it).

There are many ways to initialize a pointer:

  • Suppose you declare a pointer which points to an integer value, like

int *ptr, now this pointer doesn’t have a valid address. We can use the

address of another variable and assign this address to our pointer like

int variable1;

ptr = &variable1;

‘&’ ampersand is used to get memory location of the integer variable.

  • Another way is dynamic memory allocation. In this technique pointer is

    assigned a valid address at run time from the heap segment. This is the best way to assign addresses to pointers as it gives us the flexibility of deciding the amount of memory we want our pointer to access and the type of data we will store in the block of memory. Dynamic allocation of memory is done using malloc(), calloc(),and realloc() system calls.

    For e.g. lets assign an address to ptr

    ptr = (int*)malloc(sizeof(int) * 10);

Here, we type cast malloc to tell the compiler that we want a memory block

that stores integers and we use the sizeof() function to find the size of ‘int’ in

our system and multiply it by the no. of integers we want to store in this

block.

ptr would store the starting address of this block of memory.

  • This last method is specific to character arrays

    for e.g. char *ptr = “Hello world”

    ‘ptr’ is a pointer which would store the address at which a character is to be stored. In our e.g. ptr would hold the address at which ‘H’ is stored using this

    address we access the entire string. Note that the string will be automatically terminated by ‘\0′.

Reading Complicated Pointer Declarations:

We’ll use an e.g. to understand how we should interpret complicated pointer

declarations.

int*(*(*ptr[]) () )[]

We should start from the identifier(and the innermost brace) and move right

then left until we reach

end brace so we start from ptr:

  • ptr is the identifier we can straight away conclude that ptr is an array

    (on moving right) of (on moving left)pointers, after square brackets the innermost braces close. So we’re at *ptr[]

  • Next on moving right ptr is an array of pointers to a function (then moving left) that returns pointer. At this point we’re at

    (int*(*ptr[])() )

  • Finally the outermost braces ptr is an array of pointers to a function returning pointer to (on moving right) an array of integer pointers(on moving left).

Posted in Data Structures with C | Leave a comment

Interprocess communication using message queues at the requesting side and shared memory at the processing side with three clients successfully implemented.

RCS file: header.h,v
Working file: header.h
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
>> header file: contains header files which are required in the program mostly named stdio.h,sys/shm.h,sys/ipc.h,sys/types.h,sys/msg.h
=============================================================================

RCS file: server.c,v
Working file: server.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is main server..
here request is recieved using message queues
request is written to the shared memory
result is fetched back from the shared memory
and then result is sent back to the requesting clients using message queues.
=============================================================================

RCS file: c1.c,v
Working file: c1.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is requesting client contains request for the add operation
the request is sent to the server using message queues
and the result is recieved back from the server using message queues
=============================================================================

RCS file: c2.c,v
Working file: c2.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is requesting client contains request for the multiply operation
the request is sent to the server using message queues
and the result is recieved back from the server using message queues
=============================================================================

RCS file: c3.c,v
Working file: c3.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is requesting client contains request for the subtraction operation
the request sent to the server using message queues
and the result is recieved back from the server using message queues
=============================================================================

RCS file: p1.c,v
Working file: p1.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is processing client..here adding operation is performed..
request is retrieved using shared memory
and result is written back to the shared memory
=============================================================================

RCS file: p2.c,v
Working file: p2.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
second processing client..here subtraction operation is performed
request is retrieved using shared memory
and result is written back to the shared memory
,
=============================================================================

RCS file: p3.c,v
Working file: p3.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is third processing client ..here multiplication operation is performed
request is retrieved using shared memory
and result is written back to the shared memory
=============================================================================

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

Pointers

Pointers are just variables like any other variables we declare, the only difference is that, the so called normal variables store some sort of data like an integer,a character,a floating point number, on the other hand a pointer stores a logical address belonging to the data or stack segment (at which some data is stored or is to be stored).
A pointer provides us the ability to access and modify data from anywhere. Pointers allow faster access to memory.
 
Pointer declaration:
 
The ‘*’ operator is used to declare a pointer for e.g. int *ptr or char *ptr. In the former case ptr is a pointer which would hold the memory location of an integer similarly in the latter ptr is a pointer which would store the memory location of a character. Its important to note that the datatype preceding the identifier is not the datatype of the identifier its the datatype of the value that would be stored or is already present at the location ptr is pointing to.
 
Pointer Initialization:
 
Its important to remember that a pointer when declared does not store a valid logical address, rather it holds a garbage value and such pointers are called wild pointers and are very dangerous as they may be pointing to a location where some data is already stored and you might end up overwriting it. So its essential to give a valid address to the pointer (You shouldn’t worry too much about this as the compiler would give you a segmentation fault at run time if you try to access a wild pointer, but its a good habit to initialize the pointer as soon as you declare it).
 
There are many ways to initialize a pointer:
  • Suppose you declare a pointer which points to an integer value, like int *ptr, now this pointer doesn’t have a valid address. We can use the address of another variable and assign this address to our pointer like
int variable1;
ptr = &variable1;
‘&’ ampersand is used to get memory location of the integer variable.
  • Another way is dynamic memory allocation. In this technique pointer is assigned a valid address at run time from the heap segment. This is the best way to assign addresses to pointers as it gives us the flexibility of deciding the amount of memory we want our pointer to access and the type of data we will store in the block of memory. Dynamic allocation of memory is done using malloc(), calloc(),and realloc() system calls.
    For e.g. lets assign an address to ptr
                         ptr = (int*)malloc(sizeof(int) * 10);
Here, we type cast malloc to tell the compiler that we want a memory block that stores integers and we use the sizeof() function to find the size of ‘int’ our system and multiply it by the no. of integers we want to store in this block. ptr would store the starting address of this block of memory.
  • This last method is specific to character arrays
    for e.g. char *ptr = “Hello world”
    ‘ptr’ is a pointer which would store the address at which a character is to be stored. In our e.g. ptr would hold the address at which ‘H’ is stored using this address we access the entire string.
Note that the string will be automatically terminated by NULL character. Another point to remember is that this is a declaration for a const char* that means the string pointed to by ptr cannot be changed. An  attempt to modify this string will not result in a compile time error, rather at run time a segmentation fault will occur. A better option is to initialise ptr as :
                     const char *ptr = “Hello World”;
Modifying ptr now would give compile time error, which is better because both statements give the same result, a const char array, so a compile time error saves us time and reduces the confusion.
 
Reading Complicated Pointer Declarations:
 
Reading complex pointer declarations can become a nightmare especially for people who are new to C. So, I’ve added an e.g. w.r.t this topic just to complete my share social service for this week.
We’ll use the following e.g. to understand how we should interpret complicated pointer declarations.
int*(*(*ptr[]) () )[]
We should start from the identifier(and the innermost brace) and move right then left until we reach an end brace. So here we start from ptr:
  • ptr is the identifier we can straight away conclude that ptr is an array (on moving right) of (on moving left) pointers, after square brackets the innermost braces close. So we’re at *ptr[]
  • Next on moving right ptr is an array of pointers to a (on moving right) function (then moving left) that returns a pointer. At this point we’re at (int*(*ptr[])() )
  • Finally the outermost braces give us : ptr is an array of pointers to a function returning pointer to (on moving right) an array of integer pointers(on moving left).
I’ll take another e.g. and explain it in more detail to make things clear:
char (*(*ptr())[])()
  • Using our convention we start from ptr, now moving right we see that ptr is a function , then we reach the end of the innermost brace but we still don’t know what this function returns to find out we move to the left of ptr and find ‘*’ operator so we conclude that ptr is a function that returns a pointer. At the end of this we’re at: *ptr() (ptr is a function returning a pointer), but we don’t know what the returning pointer points to.
  • Going out of the inner most braces on the right we see square brackets so that means the pointer returned by ptr would point to an array, now on moving left we find what this array stores. It stores pointers. So at this stage we have : *(*ptr())[] (ptr is a function returning a pointer to an array of pointers). Remember we don’t know the pointers in the array point to.
  • Now to the outermost braces on moving right its clear that the pointers in the array each point to a function and on moving left we find the return type of these functions is a char type variable.
So we can conclude that ptr is a function returning a pointer to an array of pointers which point to functions that return char type variables.
 
I’ll leave a few exercises and there answers so that you can become accustomed to this method.
  1. *(*(*arr[3]))[3]
  2. *(*arr[5])( ))
  3. char(*ptr)( )
Answers:
  1. ‘arr’ is an array ( of size 3 ) of pointers each of which points to a pointer that points to an array ( of size 3 ) of pointers.( Remember if you encounter nothing on the right simply move to the left)
  2. ‘arr’ is an array ( of size 5 ) of pointers each of which points to a function that returns a pointer.
  3. ‘ptr’ is pointer to a function that returns a char type variable.

 

Posted in Uncategorized | Leave a comment

Successfully done process comm. using message queue for single client

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:
this is header file
—————————-
revision 1.1
date: 2015/04/06 06:08:57; 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:
implement msg queue at req side
implement fifo at pro side
—————————-
revision 1.1
date: 2015/04/06 06:08:47; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: req_add.c,v
Working file: req_add.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
implement msg queue
send reqyest to server
—————————-
revision 1.1
date: 2015/04/06 06:09:11; author: root; state: Exp;
Initial revision
=============================================================================

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:
take data from server using command line arguments
—————————-
revision 1.1
date: 2015/04/06 06:09:15; author: root; state: Exp;
Initial revision
=============================================================================

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

Inter process communication using message queues with three requesting clients and three processing clients implemented successfully

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
define header files thar are required for the implementation of message queues at the requesting side and pipes at the processing side
gave prototype for the request strcture
gave prototype for the block of data that has to be sent to server via message queues
gave prototype for the result structure that has to be captured by requesting client from server side via meaasge queues
gave prototype for the functions used for invoking the processing clients.
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

RCS file: c1.c,v
Working file: c1.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
here request for addition is present that has to be sent to server via message queues
and result is captured via another message queue
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

RCS file: c2.c,v
Working file: c2.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
here request for subtraction is present that has to be sent to server via message queues
and result is captured via another message queues
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

RCS file: c3.c,v
Working file: c3.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
here request for multiplication is present that has to be sent to server via message queues
and result is captured via another message queue
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

RCS file: p1.c,v
Working file: p1.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
here addition operation is performed on the request sent by the server via pipe and then the result is transferred back to the server via pipe using signals.
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

RCS file: p2.c,v
Working file: p2.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
here subtraction operation is performed on the request sent by the server via pipe and then the result is transferred back to the server via pipe using signals
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

RCS file: p3.c,v
Working file: p3.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
here multiplication operation is performed on the request sent bye the server via pipe and then the result is transferred back to the to the server via pipe using signals
—————————-
revision 1.1 locked by: psingh;
date: 2015/04/05 01:44:07; author: psingh; state: Exp;
Initial revision
=============================================================================

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

Successfully done IPC using message queue for 3 requesting and 3 processing clients.

RCS file: server.c,v
Working file: server.c
head: 1.6
branch:
locks: strict
root: 1.6
access list:
symbolic names:
keyword substitution: kv
total revisions: 6; selected revisions: 6
description:
RCS file: server.c,v
Working file: server.c
head: 1.6
branch:
locks: strict
root: 1.6
access list:
symbolic names:
keyword substitution: kv
total revisions: 6; selected revisions: 6
description:
This is the base file for IPC via message queue for 3 requesting and 3 processing clients.
Created 3 requesting and 3 processing clients and a server.
Created message queue in server and linked 3 requesting clients with server via message queue.
—————————-
revision 1.6 locked by: root;
date: 2015/04/04 04:58:22; author: root; state: Exp; lines: +1 -0
Forwarded result to requesting clients via message queue.
printed result on requesting clients successfully.
—————————-
revision 1.5
date: 2015/04/04 04:57:40; author: root; state: Exp; lines: +0 -1
collected result on the server side.
printed result on server.
—————————-
revision 1.4
date: 2015/04/04 04:56:34; author: root; state: Exp; lines: +0 -1
Forwarded result from processing clients to server via pipes.
used signals to avoid blocking of pipes.
—————————-
revision 1.3
date: 2015/04/04 04:55:22; author: root; state: Exp; lines: +1 -0
Forwarded request to processing clients via pipes.
collected request at processing clients.
Calculated and printed result on processing clients.
—————————-
revision 1.2
date: 2015/04/04 04:53:54; author: root; state: Exp; lines: +0 -1
Linked processing clients to server via pipes.
Sent request from requesting clients to server via message queue.
used semaphores to provide synchronization.
collected and printed request on server.
—————————-
revision 1.1
date: 2015/04/04 04:52:40; author: root; state: Exp;
Initial revision
=============================================================================
This is the base file for IPC via message queue for 3 requesting and 3 processing clients.
Created 3 requesting and 3 processing clients and a server.
Created message queue in server and linked 3 requesting clients with server via message queue.
—————————-
revision 1.6 locked by: root;
date: 2015/04/04 04:58:22; author: root; state: Exp; lines: +1 -0
Forwarded result to requesting clients via message queue.
printed result on requesting clients successfully.
—————————-
revision 1.5
date: 2015/04/04 04:57:40; author: root; state: Exp; lines: +0 -1
collected result on the server side.
printed result on server.
—————————-
revision 1.4
date: 2015/04/04 04:56:34; author: root; state: Exp; lines: +0 -1
Forwarded result from processing clients to server via pipes.
used signals to avoid blocking of pipes.
—————————-
revision 1.3
date: 2015/04/04 04:55:22; author: root; state: Exp; lines: +1 -0
Forwarded request to processing clients via pipes.
collected request at processing clients.
Calculated and printed result on processing clients.
—————————-
revision 1.2
date: 2015/04/04 04:53:54; author: root; state: Exp; lines: +0 -1
Linked processing clients to server via pipes.
Sent request from requesting clients to server via message queue.
used semaphores to provide synchronization.
collected and printed request on server.
—————————-
revision 1.1
date: 2015/04/04 04:52:40; author: root; state: Exp;
Initial revision
=============================================================================

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

Inter process communication using fifo at the requesting side and pipes at the processing side using semaphores and signals.

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
gave header files which are required for the fifo and semaphore implementation.
gave prototypes for the request structure
gave prototype for the semaphore union
gave prototypes for the invoke_process functions
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

RCS file: c1.c,v
Working file: c1.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
thi is first requesting client
here request for addition is sent to the server side
including semaphores and signals
request has been sent through the fifo to the server
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

RCS file: c2.c,v
Working file: c2.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
this is second requesting client
here request for subtraction sent to server side
using semaphores and signals
request sent through fifo
result read through another fifo
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

RCS file: c3.c,v
Working file: c3.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
this is third requesting client
here request for multiplication sent thorugh fifo to the server side
using semaphores and signals
result read through another fifo from the server’s end
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

RCS file: p1.c,v
Working file: p1.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
this is the processing client
here addition operation is performed on the request sent by the requesting client
result is send through the pipe to the servers end using signals
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

RCS file: p2.c,v
Working file: p2.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
this is the second processing client
here subtraction operation is performed on the request sent by the requesting client
result is sent back to the server’s end using pipes and signals
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

RCS file: p3.c,v
Working file: p3.c
head: 1.1
branch:
locks: strict
psingh: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
this is third processing client
here operation of multiplication is performed on the request sent by the requsting client
result is sent back to the server using pipes and signals
—————————-
revision 1.1    locked by: psingh;
date: 2015/04/03 18:51:58;  author: psingh;  state: Exp;
Initial revision
=============================================================================

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

Successfully done IPC using FIFO for 3 requesting and 3 processing clients using semaphores.

RCS file: server.c,v
Working file: server.c
head: 1.5
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
This is the base file for IPC using FIFO for 3 requesting and 3 processing clients.
—————————-
revision 1.5
date: 2015/04/01 04:21:45; author: root; state: Exp; lines: +0 -1
Reseived result on requesting clients.
printed result on requesting clients.
—————————-
revision 1.4
date: 2015/04/01 04:17:53; author: root; state: Exp; lines: +1 -0
Calculated result on processing clients.
Sent result back to server using signals via pipes.
—————————-
revision 1.3
date: 2015/04/01 04:14:49; author: root; state: Exp; lines: +0 -1
printed request on server and forwarded it to respective processing clients.
printed result on processing clients.
—————————-
revision 1.2
date: 2015/04/01 04:12:56; author: root; state: Exp; lines: +1 -0
Created 3 requesting and 3 processing clients.
Transfered request from requesting clients to server via fifo using semaphores.#[D
—————————-
revision 1.1
date: 2015/04/01 04:12:00; author: root; state: Exp;
Initial revision
=============================================================================

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

Successfully done IPC using FIFO for Multiple clients with Semaphores

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

Successfully done IPC using FIFO for single client with Semaphores

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

Successfully done IPC using FIFO for 2 requesting and 2 processing clients using semaphores.

RCS file: server.c,v
Working file: server.c
head: 1.4
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
This is the base file for IPC using fifo for 2 requesting and 2 processing client using semaphores.
—————————-
revision 1.4
date: 2015/03/31 17:00:02; author: root; state: Exp; lines: +2 -1
Sent result back to requesting client via fifo using semaphore.
printed result at requesting clients.
—————————-
revision 1.3
date: 2015/03/31 16:58:58; author: root; state: Exp; lines: +0 -1
Received result from processing client to server using signal.
printted result on server
—————————-
revision 1.2
date: 2015/03/31 16:57:09; author: root; state: Exp; lines: +1 -0
Created two requesting and two processing clients.
Transfered data from requesting clients to server through pipe.
forwarded data to processing clients via pipes.
—————————-
revision 1.1
date: 2015/03/31 16:56:36; author: root; state: Exp;
Initial revision
=============================================================================

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

Successfully done IPC using FIFO for single requesting and processing client using semaphore.

RCS file: server.c,v
Working file: server.c
head: 1.4
branch:
locks: strict
root: 1.4
access list:
symbolic names:
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
This is the base file for IPC using FIFO and Semaphores for 1 req and 1 processing client.
Here Request is written to server by reqesting client via semaphore.
—————————-
revision 1.4 locked by: root;
date: 2015/03/30 11:18:13; author: root; state: Exp; lines: +1 -0
Successfully printed result on requesting client..
—————————-
revision 1.3
date: 2015/03/30 11:16:57; author: root; state: Exp; lines: +1 -0
Wrote result back to requesting client from server….
Used signal and semaphore to provide synchronization.
—————————-
revision 1.2
date: 2015/03/30 11:13:19; author: root; state: Exp; lines: +1 -1
Printed the result on processing client.
Got the result back from processing client.
—————————-
revision 1.1
date: 2015/03/30 10:55:13; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: req_add.c,v
Working file: req_add.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
This is the base file for requesting client.
—————————-
revision 1.2 locked by: root;
date: 2015/03/30 11:14:47; author: root; state: Exp; lines: +11 -11
*** empty log message ***
—————————-
revision 1.1
date: 2015/03/30 10:55:13; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: pro_add.c,v
Working file: pro_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:
This is the base file for processing client.
—————————-
revision 1.1 locked by: root;
date: 2015/03/30 10:55:13; author: root; state: Exp;
Initial revision
=============================================================================

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

socket using AF_UNIX

head 1.6;
access;
symbols;
locks
ashish:1.6; strict;
comment @ * @;

1.6
date 2015.03.29.13.01.22; author ashish; state Exp;
branches;
next 1.5;

1.5
date 2015.03.29.12.57.43; author ashish; state Exp;
branches;
next 1.4;

1.4
date 2015.03.29.12.56.00; author ashish; state Exp;
branches;
next 1.3;

1.3
date 2015.03.29.12.54.16; author ashish; state Exp;
branches;
next 1.2;

1.2
date 2015.03.29.12.44.26; author ashish; state Exp;
branches;
next 1.1;

1.1
date 2015.03.29.12.40.43; author ashish; state Exp;
branches;
next ;

desc
@showing communication between two file using socket by using AF_UNIX
@

1.6
log
@in the similar way..the more client can be connected

1.5
log
@now giving the connect(),call at the client side so that the req of client that can be for read or write operation,can be listen at the side of server
at the server giving the accept() call,where it creat the copy of socket created above but that would be unnamed,so that created socket will coonected to that particular client for the req came from the client
@
text
@d28 1
@

1.4
log
@now giving a call for listen,by using listen()
so that the req from the client side can be listen by server
with this call a listen queue will be created
where the req from client will be taken
@
text
@d23 1
a23 1

1.3
log
@giving the socket family and its path
socket have been created
now giving the name to the socket by using bind(),call,now the socket in the server have been created as nameed socket
same socket have been created in the client side,but that s unmaed
@
text
@d23 1
a23 1

1.2
log
@includeng the header files
creating the socket by giving the socket(),where we are using the family AF_UNIX
@
text
@d12 1
a12 1

1.1
log
@Initial revision
@
text
@d12 1
a12 1

Posted in Project 04: FTP based Client Server using Threads and Sockets | Leave a comment