RECENT ASSIGNMENT

Client and Server server written in Linux socket
client in winsocket Using TCP. I need good documentation along with step by step easy approach
sloutions.
n this project, you will develop two applications: a connectionoriented (TCP) IM (Instant message) server and a client. The implementation logic is similar to the first two programs but with some difference: 1) Use TCP as transport layer protocol. 2) Since this project will use TCP rather than UDP, there is no need for an application level message number (means no need the random 5digits number from the two projects), so that has been dropped from the message format. That means that everything following the first semi-colon should be encrypted. 3) Client servers as a client as well as a server.
Server:
Your server will need to respond to sign-on messages (message type 1) from clients. Your server should be able to support up to 5 clients at one time. It must also be able to send updates to those clients as other members join and leave the system.
It must be running in a Linux machine.
Client:
You will register with your server, but once you have signed on, you will get the names and addresses (IP and port) of all active users. Then all message passing will be directly between clients (P2P applications). When you are done, you send a sign-off message to the server and then close all of your open connections.
As with the first project, all of the information following the message type and semi-colon should be encrypted. By default, you should use the same cipher_sp14.h header used in project 1, however, there are some differences. Since this project will use TCP rather than UDP, there is no need for an application level message number, so that has been dropped from the message format. That means that everything following the first semi-colon should be encrypted.
It can be running either in a Windows or Linux machine.
A). Connection-oriented Sign-on Server
In this One, you are going to build the sign-on server that works with your TCP client. This application protocol has 3 message types:
Message 1: Sign onto system message format: (from client to server)
1;clientName;msgPort#
(Send to server a single line of text. The first element is a message type of 1, followed by a semi-colon, then followed by your username, semicolon, followed by the port that your client program listens on for incoming messages.)
Every message sent from the central server to a client will be terminated with a # character. It is expected that messages sent to the server will also be terminated with #. You may use any method you wish to handle message control between clients. But you have to specify in your report.
After server receives sign-on message from client, it will send out that client a message of type 4:
Message 4: Send a list of active users. General format will be:
4;countOfUsers
User1Name;ipAddress1;port1
User2Name;ipAddress2;port2
etc.#
When a user logs onto the server, your server should respond with a list of the other users already logged onto system (if any). If no others logged on, your server will respond with: 4;0#
As new users join the group, your server will send additional type 4 messages to all active users to announce the new arrival.
4;new
User1Name;ipAddress;port #
As users leave the group, your server will send additional type 4 messages to all active users to announce the new departure. The count of users will be negative (-1 to indicate that 1 user has left), followed by the same user identification given above.
4;-1
User1Name;ipAddress#
Message 3: Online status check. The sign-on server should regularly send a quick message (of the format shown below) to every user that the server thinks is still active. By checking the return value of the send() function, the server knows if the user is still logged on or not. If not, the user is dropped from the server, and a type 2 message indicating the drop is sent to all existing users.
Format:
3;StatusCheck#
No response is needed by the client program.
Error Messages: There are a number of possible errors that the central server should detect. You need to implement all of them. They are:
Error;Buddy List is full. Please try back later. # The server can support 5 simultaneous users at the same time. If you get more users than that, this message will be generated.
Error;User number invalid. Try again # The username can not exceed 24 characters
Error:User exits. # The username has been used
Error;Invalid connection request: ..logon message received # Something was invalid in the logon message received. The message received is returned to the user. This could be the lack of a sentinel character, or something wrong in the message format.
Error;Message port number is invalid. Please try again # The port number that is specified in the logon message is not a valid number. It should be 5 characters and between 1025 and 65535.
Error;Invalid request for a new connection # Server received a new connection request, but message type was not 1._
Your sign-on server should periodically (at least once a minute) send a StatusCheck message to all users. There are a number of ways that you might implement this, but note that you will need to maintain a connection with all clients who you believe to still be active. One way to do this is to use the select function to monitor the connections to the sign-on server and the port that is listening for incoming connection requests. However, to be able to send messages, you will need to make this select a nonblocking function. You do that by specifying a time limit on how long the select function waits for an incoming message. The select function uses a “timeval” data type that includes a seconds component (tv_sec) and a microseconds component (tv_usec). It can be used as follows:_
timeval myTime;_ myTime.tv_sec = 60;_ myTime.tv_usec = 0;_ This will declare an instance of the timeval data type and set it equal to 60 seconds. _If the timer times out
before any of the sockets get
work (return value from
select = 0), then your server
program should check all connections to verify that they are still active._Note that there may be many other ways to implement this application, and any approach that uses TCP and
uses some sort of
concurrency will be fine. If
in doubt, we can discuss
this._
1). I want you also to implement a server side logging system which logs all communication in a nice format.
___
B). Connection-oriented Client/Server
In this one, You are to build a P2P IM client/server that will connect to your server that maintains a list of active users. Once you have obtained a list of active users (and their name, IP address and port number), all messages go directly between users. The application protocol has 4 message types:
Message 1: Sign onto system message format:
1;myName;msgPort#
Send to server a single line of text. Message type is 1, followed by semi-colon, then followed by your username, followed by the port that your program listens on for incoming messages, terminated by #. !!! Your username can be an arbitrary length (24 characters or less) but the port number should always be 5 digits (leading 0s if needed). Everything starting with myName should be encrypted. Note that this server will test for unique user names.
Please be sure to terminate all messages with a #. This might not be a true sentinel character, but it will be fairly reliable and it will ensure that all users (and the server) can properly interpret the messages.
Message 2: Send a message to another user:
2;myName buddyName message#
(First line includes message type (2), semi-colon, sender’s name.)
(Second line includes only the receiver’s name)
(Third line contains the message, terminated by #.)
As with the first assignment, this 3 line message should be sent as a single packet. That means that you will need to add carriage returns (‘ ’) after myName. and buddyName.
After the message, you should add an #. Everything starting with myName should be encrypted. The message will look like:
2;myName buddyName message#
Messsage 3: Ongoing status check. The sign-on server will regularly (every 10 seconds or so) send a quick message (of the format shown below) to every user that the server thinks is still active. From that query, the server knows if the user is still logged on or not. If not, the user is dropped from the server. Format:
3;StatusCheck#
The -StatusCheck#- portion of the message will be encrypted. No response is needed by the client program.
The client can just ignore the message, or provide any processing that it wishes.
Message 4: Receive a list of active users. Format:
When you log onto the system, the server will respond with a list of the other users already logged onto system (if any).
4;countOfUsers
User1Name;ipAddress1;port1
User2Name;ipAddress2;port2
Etc.#
Everything following the first semi-colon will be encrypted.
If no others are logged on, Server will respond with:
4;0#
As new users join the group, the server will send additional type 4 messages to all active users to announce the new arrival(s).
4;new
User1Name;ipAddress1;port1 #
If a user logs off from the system, the server will respond with
4;-1
User1Name;ipAddress1;port1#
Error messages: Your client can response to Error message from server (see server’s Error code). The format for those error messages will be:
Error;some message ... #
You client also need to check the Errors by itself: such as
1). Your target client is not online anymore.
2).Your message is wrong.
Program Implementation Considerations
Server Side:
1. All text following the first semicolon will be encrypted.
2.
Client Side:
1. All text following the first semicolon will be encrypted.
2. Client can immediately update its user list based on the server’s message
3. Every message between clients will represent a separate connection.
That is, you will need to accept the connection, then display the message, and then close the connection to that user.
There are a number of ways that you might implement this, but note that you will need to maintain a connection with the sign-on server, you will need to be able to accept an incoming connection request, AND you will need to be able to send a message.
One way to do this is to use the select function to monitor the connection to the sign-on server and the port that is listening for incoming connection requests. However, to be able to send messages, you will need to make this select a non-blocking function. You might do that by specifying a time limit on how long the select function waits for an incoming message. The select function uses a “timeval” data type that includes a seconds component (tv_sec) and a microseconds component (tv_usec). It can be used as follows:
timeval myTime;
myTime.tv_sec = 2; myTime.tv_usec = 0;
This will declare an instance of the timeval data type and set it equal to 2 seconds.
If the timer times out before any of the sockets get work (return value from select = 0), then your client program should ask the user if they wish to send a message.
Another approach might be to use multiple threads to manage each of the functions. There may be many other ways to implement this application, and any approach that uses TCP and uses some sort of concurrency will be fine. If in doubt, discuss it with me.
I also want you to implement a group messaging command (message 5). This message will send a message to everyone who is currently logged in. This means that your client will establish a separate connection to each existing client, send the message, and then close that connection.