[7.7] chat server

1. Example

A online --msg--> B online
A online --add friend-> B offline
A offline<--see-- B online

What is our chat server?
1. support a small number of users
2. ppl have a contact list to see who is online vs  offline

What specifies actions does it need to support?
- User A signs online

- User A ask for their contact list, with each person's current status
- Friends of User A now see User A as online
- User A add User B to contact list
- User A sends text-based message to User B
- User A changes status message and/or status type
- User A removes User B

- User A signs offline


What can we learn about these requirements?
- We must have
1.a concept of users,
2. add request status,
3.online status,
4. messages.


What are the core components?
1. Database
2. Server
3. XML
We' ll need a database to store items and an "always online" application as the server.
We might recommend using XML for the communication between the chat server and the clients, as it's easy for a person and a machine to read.




What are the key objects and methods?
hidden details such as how to actually push the data to a client




2. Implementation

enum StatusType
{
   online, offline, away
}
class Status
{
    StatusType status_type;
    String status_message;
}
class User
{


   // Field: my ID
   String username;
   String display_name;

   // Field: my friend list
   User[] contact_list;
   // Field: my ongoing friend list
   AddRquest[] requests;



   // Method: modify status and short description
   boolean updateStatus(  StatusType stype, Strign message ){....;}
   // Method: add people
   boolean addUserWithUsername(String name);
   // Method: I aprove someone
   boolean approveRequest(String username);
   // Method: I reject someone
   boolean denyRequest(String username);
   // Mehtod: I remove some friends
   boolean removeContact(String username);
   // Method: CHAT MAIN FUNCTION - I CHAT, send message
   boolean sendMessage(String usernname, String message);
}

/* Hold data that from_user would like to add to_user */
class AddRequest
{
    User from_user;
    User to_user;
}
class Server
{
   User getUserByUsername(String username);
}

3. Similar Ones

What problems would be the hardest to solve(or the most interesting)?
Q1 How do we know if someone is online- I mean, really ,really know?

While we would like users to tell us when they sign off, we can't know for sure. A user's connection might have died, for example. To make sure that we know when a user has signed  off. we might try regularly pining the client to male sure it's still there.

Q2 How do we deal with conflicting information ?

We have some information stored in the computer's memory and some in the database. What happens if they got out of sync? which one is "right"?

Q3  How do we make our server scale?

While we designed out chat sever without worrying -- too much --- about scalability, in real life this would be a concern. We'd need to split our data across many servers, which would increase our concern about out of sync data.

Q4  How do we prevent denial of service(DOS) attacks?

Clients can push data to us -- what if they try to DOS us? How do we prevent that?
https://msdn.microsoft.com/en-us/library/cc750213.aspx
http://static.planetminecraft.com/files/resource_media/screenshot/1306/Cisco-what-is-ddos-attack_4812859_lrg.jpg


http://docs-legacy.fortinet.com/cb/html/index.html#page/FOS_Cookbook/UTM/cb_utm_ip_dos.html

A DOS attack really shouldn't be handled by your HTTP server. Once a request has reached it the attacker has 'won' by taking up a connection (no matter how short). Even if they are short they can just slam it with thousands/sec and prevent anyone else from connecting. Also, they might not attempt to 'connect' via TCP and just flood the server with all sorts of requests.

Block/detect DOS attacks at a lower level or via a firewall, which I'm sure many software and hardware versions support some basic types of DOS detection and prevention.

http://corporatecomplianceinsights.com/what-is-a-ddos-attack-and-how-can-you-prevent-one/

While there are many varieties of DoS and DDoS attacks, they can generally be categorized as one of two types: network‐based, or application‐based. In a network‐based attack, the attacker floods the victim computer with information, clogging up the victim computer’s communication lines and overwhelming the victim computer’s ability to process the flood of information. Some of the historically more common techniques include:

• Ping Floods: In this relatively simple type of attack, the attacking computer sends a flood of requests (or “pings”) to the victim computer that ask the victim computer to acknowledge that the victim computer is able to communicate with the attacker. If enough of these ping requests are sent, it can overwhelm the victim.
• Smurf or Fraggle Attacks: In these attacks, the attacking computer falsifies (or “spoofs”) its Internet Protocol address so that it appears to be the same as the victim’s computer. The attacker, posing as the victim, then sends requests to an entire network of computers seeking an acknowledgment. The entire network then sends its acknowledgment to the victim’s computer, flooding it with information.
• SYN/ACK Flood: These attacks exploit the way computers acknowledge each other when they first communicate over the Internet. The attacking computer introduces itself, pursuant to standard Internet protocol, with a “SYN” message. The computer responds with the standard “SYN‐ACK” message and waits for the attacking computer to issue the standard “ACK” acknowledgement. The attacker never issues this acknowledgement, which has the effect of making the victim computer expend its resources waiting. A flood of these mismatched communications can take the victim computer out of commission.

The second broad category of DoS and DDoS attacks is application‐based attacks. While conceptually similar in some ways to network‐based flooding attacks, application‐based attacks, as the name suggests, focus on exploiting software programs or applications on the victim computer in an attempt to make the computer crash or slow to a crawl. An attacker carrying out such a request may seek, for example, to repeatedly run resource‐intensive search requests on a victim’s search engine or database, or to repeatedly request complex and feature‐rich web pages from a server, either of which may severely tax or exceed the victim server’s capacity.

The organized group of attacking computers used in a DDoS attack is often called a “botnet” (as in “robot network”). To assemble a botnet, an attacker often will infect the computers of unsuspecting users with malicious software that allows the attacker to remotely control those computers. The user of the infected computer often will be completely unaware that the computer has been infected. Less enterprising or technically adept attackers can simply rent botnets from the web’s black market. There also have been occasions in which botnets have consisted of volunteers who willingly allow their computers to be controlled by the DDoS attacker. This often occurs in politically‐motivated attacks, as in the Wikileaks‐related attacks coordinated by the “Anonymous” organization. The recruiting and coordination of such voluntary botnets often occurs on social media sites such as Twitter, as well as in online chat rooms.

Hardware and Structural Defense: Of course, monitoring and having a response plan alone will do nothing to stop DoS and DDoS attacks, or lessen their severity. For that, you will need to consider hardware and structural defenses. For example, most modern network hardware can be configured to prevent Ping, Smurf/Fraggle, SYN/ACK, and similar DoS network flood attacks by rejecting or limiting the Internet traffic that characterizes those types of attacks (i.e., an unusually high number of “ping” requests from one computer, or a computer that refuses to issue the “ACK” message). Hardware‐implemented access control lists can also be used to filter out traffic from particular attacking computers.

These “limiting” or “filtering” solutions, however, are less useful in defending against DDoS attacks. Because DDoS attacks are perpetrated through several different computers acting in concert (often hundreds or thousands of them), they can confuse or circumvent measures taken to limit or filter the requests coming from a small number of specifically identified computers. Planning an adequate DDoS defense therefore should involve considering structural defenses as well – in other words, defenses that involve the manner in which a computer network, and the information it contains, is organized. Even these structural defenses, however, may have limited effectiveness in preventing or remediating the attacks.

Perhaps the simplest structural solution is to have an extraordinary amount of network capacity and processing power, so that your entity can withstand nearly any DDoS “flood.” While some larger entities can do this, for most it is simply not cost effective. More practical structural solutions can include: outsourcing to a large and well‐established hosting provider that is likely to have a larger amount of capacity and in‐house methods of addressing DDoS attacks; having a backup “mirror” website hosted at a different location that can be substituted if the primary site is under attack; implementing caching systems that substitute simpler web pages in place of complex feature‐rich pages if application resources become strained; and having a system architecture that clearly separates the “front‐end” web‐facing system from the “back end” processing systems to minimize the business effects of attacks on the web server.

Reporting: It is indisputably difficult to investigate and hold accountable those who perpetrate DoS and DDoS attacks – but it does happen. As of the date of this article, for example, there are news reports that persons suspected of being involved in the Wikileaks-related attacks have been arrested and their residences searched for evidence. If your business is victimized by such an attack, you therefore should consider forensic preservation of the system logs and related documentation. It just may be that this information could lead to the perpetrator being prosecuted.