अनिर्दिष्ट सुविधाओं का उपयोग किए बिना गैर-अवरुद्ध टीसीपी सर्वर

परिचय

Trapexit द्वारा उत्कृष्ट लेख "ओटीपी सिद्धांतों का उपयोग करके एक गैर-अवरुद्ध टीसीपी सर्वर का निर्माण" बताता है कि ओटीपी सिद्धांतों का उपयोग करके गैर-अवरुद्ध टीसीपी सर्वर का निर्माण कैसे किया जाता है। मुझे लगता है कि हर कोई जिसने इस लेख को जल्द से जल्द सीखना शुरू कर दिया या बाद में आया। गैर-अवरुद्ध टीसीपी सर्वर का निर्माण करने के लिए, उपरोक्त लेख prim_inet मॉड्यूल से अनिर्दिष्ट कार्यक्षमता का उपयोग करता है।

मैं अच्छे या बुरे के लिए अनिर्दिष्ट सुविधाओं का उपयोग करने के लिए दार्शनिक नहीं करूंगा, कुछ "बैसाखी" निर्णयों में यह वास्तव में आवश्यक है, उत्पादन में मैं सिद्ध साधनों का उपयोग करना पसंद करूंगा। ध्यान दें, यहां तक ​​कि लेख में भी, लेखक चेतावनी देता है: " prim_inet मॉड्यूल की जांच से एक दिलचस्प तथ्य का पता चलता है कि ग्राहक सॉकेट को स्वीकार करने के लिए inet ड्राइवर को वास्तविक कॉल अतुल्यकालिक है। जबकि यह एक गैर-प्रलेखित संपत्ति है, जिसका अर्थ है कि ओटीपी टीम मुक्त है। इस कार्यान्वयन को बदलने के लिए, हम अपने सर्वर के निर्माण में इस कार्यक्षमता का फायदा उठाएंगे [1]। "

एक गैर-अवरुद्ध सर्वर द्वारा, हमारा मतलब है कि सुनने की प्रक्रिया और FSM को किसी भी अवरोधक कॉल नहीं करना चाहिए और आने वाले संदेशों (उदाहरण के लिए, कॉन्फ़िगरेशन परिवर्तन, पुनः आरंभ, आदि) के लिए जल्दी से जवाब देना चाहिए बिना टाइमआउट [2]।

ऊपर की कतरन के बारे में: समस्याएं उत्पन्न हो सकती हैं (सुनने की प्रक्रिया के साथ), यदि यह अतिरिक्त कार्यात्मक भार वहन करती है (उदाहरण के लिए, किसी भी अतिरिक्त उपयोगकर्ता एपीआई में जो ऑपरेशन के दौरान "खींचा जाना" होता है), FSM का कोई वास्तु संबंधी विचार नहीं है। अवरुद्ध कॉल शामिल होना चाहिए। इसलिए, यदि श्रोता का एकमात्र कार्य सुनना है, तो यह चिंता करने की कोई बात नहीं है कि क्या किसी कनेक्शन के लिए प्रतीक्षा करने से उसका प्रवाह अवरुद्ध हो जाएगा, यदि इस सिस्टम तत्व को पुनरारंभ करना आवश्यक है, तो पर्यवेक्षक द्वारा पूर्व-निर्धारित समय पर इसे जबरन रोक दिया जाएगा और फिर पुनरारंभ किया जाएगा (यदि नहीं सही अधिकार)। जब कोड को गर्म किया जाता है तो समस्याएं उत्पन्न हो सकती हैं (लेखक ने यह नहीं जांचा कि इस मामले में कौन सी रेक का सामना किया जा सकता है, जिसने अनुभव साझा करने की कोशिश की)।

हम गैर-अवरुद्ध टीसीपी सर्वर को केवल प्रलेखित तरीकों से लागू करने के लिए कार्य निर्धारित करते हैं।

सर्वर संरचना

कार्य के बारे में दिमाग में आने वाली पहली चीज एक अलग प्रक्रिया में कनेक्शन की अपेक्षा को लागू करना है। इस प्रकार, सर्वर संरचना को निम्नानुसार दर्शाया जा सकता है।


चित्र 1

1. application_master: main_loop / 2
2. application_master: loop_it / 4

जब अनुप्रयोग शुरू होता है, तो एप्लिकेशन_मास्टर प्रक्रिया बनाई जाती है, तार्किक संरचना में यह एक प्रक्रिया है, लेकिन भौतिक स्तर पर दो प्रक्रियाएं बनती हैं। एप्लीकेशन मास्टर आवेदन में सभी प्रक्रियाओं के समूह का नेता है।

3. हमारे टीसीपी सर्वर (पर्यवेक्षक) के पर्यवेक्षक
4. श्रोता (gen_server), श्रोता प्रक्रिया को मारना (सरल प्रक्रिया)
5. ग्राहक प्रक्रिया पर्यवेक्षक (पर्यवेक्षक)
6. श्रोता प्रक्रिया (सरल प्रक्रिया)
7. ग्राहक प्रक्रियाएं (gen_fsm)

स्रोत कोड

मुझे लगता है कि सिस्टम के सभी भागों के लिए स्रोत कोड देने का कोई मतलब नहीं है, हम केवल tcp_listener मॉड्यूल और लॉन्च होने वाली प्रक्रिया पर ध्यान केंद्रित करेंगे।

-module(tcp_listener). -behaviour(gen_server). -export([start_link/1]). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -export([accept_func/1]). -define(SERVER, ?MODULE). 1. -define(LOGIC_MODULE, tcp_fsm). 2. -record(state, { listener, %% Listening socket module %% FSM handling module }). start_link(Port) -> gen_server:start_link({local, ?SERVER}, ?MODULE, [Port], []). init([Port]) -> Options = [{packet, raw}, {active, once}, {reuseaddr, true}], case gen_tcp:listen(Port, Options) of {ok, LSocket} -> %% Create first accepting process 3. spawn_link(?MODULE, accept_func, [LSocket]), {ok, #state{listener = LSocket, module = ?LOGIC_MODULE}}; {error, Reason} -> error_logger:error_msg("Error: ~p~n", [Reason]), {stop, Reason} end. handle_call(_Request, _From, State) -> Reply = ok, {reply, Reply, State}. handle_cast(_Msg, State) -> {noreply, State}. handle_info(_Info, State) -> {noreply, State}. terminate(_Reason, #state{listener = LSocket} = _State) -> gen_tcp:close(LSocket), ok. code_change(_OldVsn, State, _Extra) -> {ok, State}. accept_func(LSocket) -> 4. {ok, Socket} = gen_tcp:accept(LSocket), error_logger:info_msg("Accept connection: ~p.\n", [Socket]), 5. {ok, Pid} = tcp_client_sup:start_child(), 6. ok = gen_tcp:controlling_process(Socket, Pid), 7. tcp_fsm:set_socket(Pid, Socket), 8. accept_func(LSocket). 

1. क्लाइंट कनेक्शन प्रोसेसिंग मॉड्यूल की घोषणा करने वाला मैक्रो।
2. जीन-सर्वर की स्थिति को संग्रहीत करने के लिए संरचना।
3. हम एक अतिरिक्त प्रक्रिया उत्पन्न करते हैं जो "सुनो" होगी।
4. हम कनेक्शन की प्रतीक्षा कर रहे हैं।
5. क्लाइंट के साथ कनेक्शन को संभालने के लिए gen_fsm (tcp_fsm मॉड्यूल) बनाएं।
6. चरण 5 में नव निर्मित प्रक्रिया के लिए सॉकेट को नियंत्रित करने वाली प्रक्रिया को बदलें।
7. हम सॉकेट को tcp_fsm मॉड्यूल से पास करते हैं।
8. हम फिर से "सुनना" शुरू करते हैं।

परीक्षण

 (emacs@host)2> make:all(). #  Recompile: tcp_server_sup Recompile: tcp_listener Recompile: tcp_fsm Recompile: tcp_client_sup Recompile: erltcps up_to_date (emacs@host)3> code:add_path("../ebin"). #    ebin true (emacs@host)4> application:load(erltcps). #   ok (emacs@host)5> application:start(erltcps). #   ok (emacs@host)6> =INFO REPORT==== 22-Jun-2011::13:10:07 === Accept connection: #Port<0.2353>. #   (emacs@host)6> =INFO REPORT==== 22-Jun-2011::13:10:07 === IP: {127,0,0,1} # IP  (emacs@host)6> =INFO REPORT==== 22-Jun-2011::13:10:15 === <<"hello\r\n">> #   (emacs@host)6> =INFO REPORT==== 22-Jun-2011::13:10:23 === {127,0,0,1} Client disconnected. #   (emacs@host)6> 

निष्कर्ष

नतीजतन, हमने टीसीपी सर्वर के ढांचे का निर्माण किया "जैसे कि" अवरुद्ध नहीं। हमारे कार्यान्वयन में, एक विशेष प्रक्रिया अवरुद्ध रहती है, जिसका एकमात्र कार्य कनेक्शन की प्रतीक्षा करना और इसे संसाधित करने के लिए एक प्रक्रिया बनाना है। आप स्वयं tcp_listener मॉड्यूल में अतिरिक्त तर्क जोड़ सकते हैं (उदाहरण के लिए, सुनने की प्रक्रिया को रोककर कनेक्शन प्राप्त करना / शुरू करना बंद करें)।
पेशेवरों:

• हमने अनिर्दिष्ट सुविधाओं का उपयोग नहीं किया, जो उत्पादन में हमें बहुत महंगा पड़ सकता है।
• इसके लिए विशेष रूप से बनाई गई प्रक्रिया अवरुद्ध रहती है।

विपक्ष:

• हमारे ओटीपी आवेदन में, ओटीपी के सिद्धांतों के अनुसार नहीं बनाई गई एक प्रक्रिया है।
• यदि सुनने की प्रक्रिया क्रैश हो जाती है (tcp_listener मॉड्यूल में accept_func / 1), सिग्नल प्रचारित करता है, और tcp_listener भी क्रैश हो जाता है, क्योंकि पर्यवेक्षक tcp_listener को पुनः आरंभ करता है, और यह बदले में accept_func / 1 फ़ंक्शन से सुनने की प्रक्रिया को फिर से बनाता है।

ये दोनों मंत्रालय आपस में जुड़े हुए हैं। सभी के लिए एक निर्णय है। यहाँ पाठकों के लिए कुछ कार्य हैं:
1. क्या करने की ज़रूरत है ताकि सुनने की प्रक्रिया के दुर्घटनाग्रस्त होने पर tcp_urtener दुर्घटनाग्रस्त न हो (accept_func / 1)?
2. OTP एप्लिकेशन में सरल प्रक्रियाओं के सुरक्षित उपयोग के लिए, क्या जोड़ा जाना चाहिए?

डाउनलोड

लेख के लिए स्रोत कोड जीथब पर डाउनलोड किया जा सकता है।

क्या पढ़ना है?

1. ओटीपी सिद्धांतों का उपयोग करके एक गैर-अवरुद्ध टीसीपी सर्वर का निर्माण
2. ओटीपी सिद्धांतों का उपयोग करके एक गैर-अवरुद्ध टीसीपी सर्वर बनाना
3. एर्लांग प्रश्न मेलिंग सूची ~ prim_inet
4. उत्कृष्ट प्रलेखन
5. एर्लांग अनुप्रयोग