Socket-based chat room realization principle
Fujian Quanzhou Data Communications Bureau Lin Tianshan (lts@www.gz.fj.cn)
---- Socket chat room Basic principle is to throw an OGI and WWW server, after the HTML specification, after receiving the browser's request, imitate the response of the WWW server, send the chat content back to the browser. In the browser, it is always in the page connection status like browsing a huge page, which is a special chat server, a simplified WWW server.
---- This compared to the CGI mode, the advantages of the Socket chat room are obvious:
Don't require a dedicated WWW server, complete the necessary work in the chat server, avoid the time-consuming CGI process. If you use a single process server, you don't need a new process every time. Data exchange is performed in memory without reading and writing. No need to refresh, reduce the flashing of the screen, reducing the number of requests to the server.
---- Let's take a look at the specific implementation process.
I. Chat server implementation process
---- The figure below is the server program process:
---- The "Handling User Input" section in the above figure can be refined to the following figure:
---- User Data Enter is transmitted through the URL, the following is a few URL instances, combined with the client flow, can better understand the system structure.
---- This is a username password all the chat user login system of 'aaa', says "Hello", then quits the resulting series of requests, where the password is encrypted with the system function CRYPT:
/ login? name = aaa & passwd = pjhoodieleipsee
/ chat? Sid = Zuyph3twhenksicnjov & Passwd = PJHiieleiPsee
/ Talk? Sid = ZuyphH3Twhenksicnjov & Passwd = PJHiieleiPsee
/ Names? Sid = ZuyphH3TWhenksicnjov
/ dotalk? Sid = ZuyphH3TWhenksicnjov
& Passwd = pjhoodieleipsee & message = Hello
/ Leave? Sid = ZuyphH3Twhenksicnjov & Passwd = PJHiieleiPsee
Second, the client specific login process
---- Let's take a look at the chat interface:
---- The chat interface consists of three frames, where the CHAT frame is a chat content display section, the Talk frame is the user input section, including chat content input, action, filtering, and management functions in this frame, Names is online list The section is displayed, this part is refreshed.
---- Let's take a look at the process of entering the chat room from the perspective of the browser.
---- 1. First browser request page: ---- http:// Host: 9148 / login? Name = name & passwd = PWD
---- At this point, a socket connection to the server chat port is generated, and a line of data is sent: ---- Get / login? Name = name & passwd = PWD http / 1.1
---- 2. The server generates a session ID, after the password is verified, sent back:
HTTP / 1.1 200 ok
Content-Type: Text / HTML
......
......
---- Then the server closes the socket join.
---- 3. After the browser receives the above HTML file, the three coupons will be opened in turn ($ SID and $ Encrypt_pass are variables): / chat? SID = $ sid & passwd = $ encrypt_pass
/ Talk? SID = $ sid & passwd = $ encrypt_pass
/ Names? SID = $ sID
---- The first join CHAT in these three joints is in the entire chat process, so from the browser's perspective, it is a large page that is not completely downloaded, the display effect is chat content Not relying on refresh to update, but constantly scroll up. It can be seen by viewing HTML code, only
, then the increasing chat content, no .---- Different two coupling after the page is sent, the socket is turned off.
---- This login chat room actually has four Socket coupling, but after the login is completed, only the chat frame of Socket is to keep the connection, which is used to receive chat information from the server, which is the key to the socket chat room.
---- In the server, all Chat Sockets that all participated in the chat is stored. When someone speaks, the server sends chat content to all Chat Socket.
---- Talk The HTML of the Names frame is actually the same as the ordinary FORM.
---- 4. After the user logins, the server is saved a table including user information:
---- In Perl implementation, we use hash structures to store information, as a Session ID as a Key index. Such a storage structure facilitates access to data and reclaims space. Each customer information is an array:
[Socket, Name, Passwd, Privilige, Filter, Login_Time, Color]
Socket: Store CHAF Socket
Name: Username
Passwd: password
PRIVIGE: Permissions
Filter: References of a user's filter list (Reference)
Login_time: Record the login time so that some timeout coupling will be cleared later
Color: User Chat Color
---- Most of the above user data is in the Login phase, and the user is filled in the password verification. Only the Chat Socket will wait until the CHAT frame is displayed. If it is more than a certain period of time, Socket still has not been filled, indicating that the browser acquires the main framework, and the user data needs to be deleted at this time.
---- Or above is the core part of the chat room, other parts, such as user registration, change code, etc. can be used along CGI chat room.
Third, there is a need to improve
---- Currently, there is current chat feature of chat, whispering, action, and additional features such as filtering user lists. The management function has completed the kick, check IP, and appointed the room. Where you need to improve in the future:
---- Stability: At present, the chat room has not been tested by large users, and stability cannot be fully guaranteed. Since it is a single process loop server, a user communication deadlock will cause all people to die. If a concurrent multi-process server is used, stability can be improved. But such systems will be much larger than server resource consumption.
---- Function: Self-built chat room has not completed, these peripheral functions can be easily added after stability.
