अभिनेता और AJAX

समानांतर कंप्यूटिंग प्रदर्शन करने वाले कार्यक्रमों को लिखने के लिए, थ्रेड का व्यापक रूप से उपयोग किया जाता है। इस तथ्य के बावजूद कि थ्रेड्स कार्यक्रमों में समानता के लचीले संगठन की अनुमति देते हैं, उनके पास कई नुकसान हैं। तथ्य यह है कि धागे स्मृति को साझा करते हैं। इसका मतलब है कि कार्यक्रम की अखंडता का उल्लंघन करने के लिए, लापरवाही के माध्यम से यह बहुत आसान है। आप इसे ताले की मदद से दूर कर सकते हैं जो कुछ कोड को साझा संसाधन तक अनन्य पहुंच प्राप्त करने की अनुमति देता है। हालांकि, खुद को ताले, इस तथ्य के अलावा कि उन्हें याद रखने की आवश्यकता है, बदले में समस्याएं पैदा करती हैं। सबसे बुरी समस्याओं में से एक गतिरोध फैलाने की क्षमता है। हालांकि, यहां तक ​​कि इसके बिना, वास्तव में अच्छी तरह से काम करने वाले मल्टीथ्रेडेड प्रोग्राम लिखना गहने के काम में बदल जाता है।

लेकिन थ्रेड्स के विकल्प हैं। मेरे लिए जाना जाता है - अभिनेताओं (अभिनेताओं) और सॉफ्टवेयर लेनदेन मेमोरी का मॉडल। इस लेख के नायक, जैसा कि शीर्षक से स्पष्ट है, पहले हैं। हालांकि, एसटीएम पर इंटरनेट पर बहुत सारे लेख हैं जो आपकी जिज्ञासा को पूरा करेंगे।

एक अभिनेता मॉडल क्या है?

इंटरनेट अभिनेता मॉडल के संदर्भ से भरा है। इसलिए, मैं केवल इतिहास, आवेदन, उपयोग के पैटर्न के बिना, अभिनेताओं के बारे में लिखूंगा।

तो, अभिनेता ऐसी वस्तुएं हैं:

• एक दूसरे के साथ राज्यों को साझा न करें;
• केवल एक-दूसरे के साथ अतुल्यकालिक संदेश भेजकर बातचीत करें;
• अभिनेता एक ही समय में किसी भी दो संदेशों को संसाधित नहीं करता है; इसके बजाय, अभिनेता प्राप्त संदेशों को एक कतार में इकट्ठा करता है और उन्हें क्रमिक रूप से संसाधित करता है।

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

वितरित कंप्यूटिंग

यह कल्पना करने के लिए समानांतर कंप्यूटिंग में क्यों आवश्यक है कि गणना एक ही भौतिक मशीन पर घूम रही है? और अगर हमारे पास एक क्लस्टर है? अत्यधिक भरी हुई परियोजनाओं के लिए यह विशेष रूप से सच है, क्योंकि जितनी जल्दी या बाद में वे एक मशीन की सीमाओं के खिलाफ आराम करते हैं। इस मामले में प्रवाह मॉडल बिल्कुल फिट नहीं है, क्योंकि धागे स्मृति साझा किया है। यदि आप वितरित सिस्टम के मामले में कुछ समान लागू करने का प्रयास करते हैं, तो नोड्स के बीच डेटा के सिंक्रनाइज़ेशन में समस्या होगी, क्योंकि विभिन्न नोड्स पर चलने वाले थ्रेड्स में साझा मेमोरी होना चाहिए। लेकिन अभिनेता केवल अतुल्यकालिक संदेशों के माध्यम से एक-दूसरे के साथ बातचीत करते हैं, जो नेटवर्क पर अच्छी तरह से प्रसारित होते हैं।

वितरित कंप्यूटिंग के लिए अभिनेताओं को एक और फायदा है। क्योंकि अभिनेता अपने राज्य को किसी के साथ साझा नहीं करता है; यह राज्य खुद को नोड्स के बीच क्रमबद्ध और स्थानांतरित करना आसान है। दूसरी ओर, एक अभिनेता को संदेशों का तुरंत जवाब देने की आवश्यकता नहीं होती है, क्योंकि सभी संदेशों को अतुल्यकालिक रूप से वितरित किया जाता है, इसलिए अभिनेता के लिए कुछ समय व्यतीत करने या एक राज्य को निष्क्रिय करने, संदेश प्रसंस्करण को थोड़े समय के लिए स्थगित करने के लिए सामान्य होगा।

मौजूदा कार्यान्वयन

परंपरागत रूप से, अभिनेता मॉडल को एरलांग और स्काला में प्रोग्रामरों के बीच प्यार किया जाता है, जहां अभिनेताओं को मूल रूप से समर्थन किया जाता है। जावा सहित विभिन्न भाषाओं के लिए पुस्तकालय हैं, जिनमें से सबसे प्रसिद्ध अक्का है। एक हब पर इस लाइब्रेरी का अवलोकन है ।

हालांकि, यहां तक ​​कि अक्का ने भी मुझे सहायक अभिनेताओं के लिए अपनी खुद की लाइब्रेरी बनाने से रोक नहीं दिया। मुझे इसकी आवश्यकता क्यों थी, मैं नीचे बताऊंगा। इस बीच, मैं आपको दिखाऊंगा कि मेरे पुस्तकालय में अभिनेता कैसे काम करते हैं।

nop.actors

मैंने अपने ढांचे में अभिनेता का समर्थन लागू किया है। तंत्र अक्का से टाइप किए गए अभिनेताओं जैसा दिखता है, और केवल अतुल्यकालिक संदेश हस्तांतरण है।

अभिनेता का वर्णन कैसे करें? इसके लिए, इंटरफ़ेस का वर्णन करना आवश्यक है, अर्थात्। अभिनेता और कार्यान्वयन द्वारा संसाधित संदेशों का सेट, अर्थात वास्तव में संदेश प्रसंस्करण। यदि हम उन भाषाओं के साथ समानताएं बनाते हैं जहां पैटर्न मिलान का समर्थन किया जाता है, तो इंटरफ़ेस का वर्णन एक बीजीय प्रकार की घोषणा के बराबर है, और कार्यान्वयन स्वयं पैटर्न मिलान के बराबर है। यहाँ एक अभिनेता के विवरण का एक उदाहरण है:

@Actor public interface Pingable { void ping(String token, Pinger pinger); } 

 @Actor public interface Pinger { void pong(String token); } 

 public class DefaultPingable implements Pingable { @Override public void ping(String token, Pinger pinger) { System.out.println("Pinging with: " + token); pinger.pong(token); } } 

और यहाँ इसका उपयोग कैसे किया जाता है:

 Pingable pingable = Actors.wrap(Pingable.class, new DefaultPingable()); pingable.ping("hello", new Pinger() { @Override public void pong(String a) { System.out.println("Ping received: " + a); } }); 

तर्कों में पारित आंकड़ों पर कुछ प्रतिबंध हैं। अनौपचारिक रूप से, उन्हें इस तरह से समझा जा सकता है कि केवल आदिम, पीओजेओ, अन्य अभिनेताओं और सूचियों को स्थानांतरित किया जा सकता है। औपचारिक रूप से, इसे निम्नानुसार वर्णित किया गया है। बता दें कि S उन सभी प्रकारों का समूह है जो संदेशों में प्रसारित होते हैं। तब:

• आदिम प्रकार और आवरण वर्ग एस में शामिल हैं;
• अभिनेता एनोटेशन के साथ चिह्नित किसी भी इंटरफ़ेस को एस में शामिल किया गया है;
• कोई एनम एस में है;
• सूची <टी>, सेट <टी>, टी [] एस दर्ज करें अगर टी एस में प्रवेश करता है;
• कोई भी वर्ग जिसमें निजी क्षेत्र शामिल हैं और उनमें से प्रत्येक के लिए एक सहायक तरीकों की एक जोड़ी एस में शामिल है यदि प्रत्येक क्षेत्र का प्रकार एस में है।

अब देखते हैं कि HTTP प्रोटोकॉल के माध्यम से अभिनेताओं को दूरस्थ रूप से कैसे उपलब्ध कराया जाता है। ऐसा करने के लिए, एक तंत्र है जो एनओपी में एकीकृत है और फ्रेमवर्क का उपयोग कर रहा है। किसी अभिनेता को दूरस्थ रूप से सुलभ बनाने के लिए, आपको ActorManager ऑब्जेक्ट पर ExportActor विधि को कॉल करना होगा। ActorManager निर्भरता इंजेक्शन के माध्यम से प्राप्त किया जा सकता है:

 public class PingController { private ActorManager actorManager; @Injected public PingController(ActorManager actorManager) { this.actorManager = actorManager; } public Content pingDemo() { ActorInfo fooInfo = actorManager.exportActor(new DefaultPingable()); //    ,    hello // ... } } 

बेशक, एनओपी ढांचे द्वारा प्रदान की गई क्षमताओं का उपयोग करना आवश्यक नहीं है। यदि आपको सभी निर्भरताओं को खींचने की आवश्यकता नहीं है, तो यह केवल HttpActorDispatcher वर्ग के साथ करने के लिए पर्याप्त है, इसे अपने सर्वलेट में रखें।

ब्राउज़र साइड अभिनेता

अभिनेताओं के सूचीबद्ध गुण बताते हैं कि अभिनेता वेब अनुप्रयोगों के लिए एकदम सही हैं, जिसमें आपको ब्राउज़र और वेब सर्वर के बीच डेटा को दोनों दिशाओं में सक्रिय रूप से आदान-प्रदान करने की आवश्यकता होती है। लेकिन इसके लिए जावास्क्रिप्ट में अभिनेता मॉडल के समर्थन की आवश्यकता है। और वह nop.actors में है!

यदि आप केवल ब्राउज़र के भीतर ही अभिनेताओं को लेते हैं, तो उनके साथ सब कुछ सरल है। सबसे पहले, अभिनेता वर्ग के निर्माता को एक अभिनेता कॉल में लपेटने की आवश्यकता होती है। दूसरे, एक वर्ग के अभिनेता को एक उदाहरण बनाने के लिए, आपको अभिनेता विधि के साथ इसे लपेटने की आवश्यकता है। यहां देखें कि यह पिंजर अभिनेता का उदाहरण कैसे होगा:

 DefaultPinger = actor(function(elem) { this.elem = elem; }); DefaultPinger.prototype.pong = function(token) { var messageElem = document.createElement("div"); messageElem.textContent = token; this.elem.appendChild(messageElem); } 

 var pinger = actor(new DefaultPinger(document.getElementById("pingResult"))); pinger.pong("hello"); 

यदि आप वेब सर्वर के किनारे अभिनेताओं के साथ ब्राउज़र की तरफ अभिनेताओं की बातचीत सुनिश्चित करना चाहते हैं, तो आपको जावास्क्रिप्ट में इंटरफ़ेस का वर्णन करना चाहिए। हमारे उदाहरण के लिए, विवरण इस प्रकार होगा:

 Pingable = {}; Pinger = {}; Pingable.ping = ["value", actorRef(Pinger)]; Pinger.pong = ["value"]; 

यहाँ सामान्य सिद्धांत यह है। जिस प्रोटोकॉल से आपको अभिनेता के साथ संवाद करने की आवश्यकता होती है, उसे एक वस्तु के रूप में वर्णित किया जाता है। ऑब्जेक्ट के गुण अभिनेताओं द्वारा संसाधित संदेशों के अनुरूप हैं। संदेश के साथ पारित तर्कों के प्रकारों को सूचीबद्ध करने के लिए संपत्ति का मूल्य हमेशा एक सरणी होना चाहिए। ढांचा निम्न प्रकार के तर्कों को समझता है:

• स्ट्रिंग "मान" किसी भी आदिम प्रकार या एनम से मेल खाता है;
• अभिनेता रीफ (ए), जहां ए अभिनेता का वर्णन है;
• एक तत्व ए की एक सरणी इंगित करती है कि तर्क एक प्रकार के तत्व के साथ एक संग्रह है;
• एक मनमाना वस्तु का अर्थ है POJO, और वस्तु के गुणों का मान POJO गुणों के प्रकार को दर्शाता है।

रिमोट अभिनेताओं के साथ काम करने के लिए ActorRemoting वर्ग जिम्मेदार है। यहां क्लास को शुरू करने और उपयोग करने का एक उदाहरण दिया गया है:

 var remoting = new ActorRemoting("/actors/" + sessionId); var pingable = remoting.importActor(Pingable, nodeId, actorId); remoting.start(pregable.ping("hello", pinger); 

बेशक, सर्वर को पहले ब्राउजर को सेशनआईड, नोडआईड और एक्टरआईड किसी तरह पास करना होगा। उदाहरण के लिए, वह ऐसा तब कर सकता है जब कोई पृष्ठ उत्पन्न करके उसमें जावास्क्रिप्ट कोड जोड़कर इन चरों को आरंभ करता है।

पूरा उदाहरण

ऊपर, मैंने अभिनेता मॉडल को एनओपी में लागू करने के बारे में बात की, दोनों सर्वर साइड पर और ब्राउज़र साइड पर। हालाँकि, कुछ समय के लिए मुझे इस बात का मलाल था कि एक छोटे से आवेदन में यह सब कैसे रखा जाए। तो, हमें निम्न वर्गों की भी आवश्यकता है:

 @Route(prefix = "pingpong") public interface PingRoute { @RoutePattern("/") String main(); } 

 @RouteBinding(PingRoute.class) public class PingController extends AbstractController { private ActorManager actorManager; @Injected public PingController(ActorManager actorManager) { this.actorManager = actorManager; } public Content main() { ActorInfo pingInfo = actorManager.exportActor(Pingable.class, new DefaultPingable()); return html(createView(PingView.class).setActorInfo(pingInfo)); } } 

 public class PingView extends Template { PingView setActorInfo(ActorInfo actorInfo); } 

 @ModuleRequires(modules = ActorsModule.class) public class PingModule extends AbstractModule { @Override public void load() { app.loadPackage(PingModule.class.getPackage().getName()); } } 

इसके अलावा, आपको निम्नलिखित सामग्रियों के साथ PingView.xml टेम्पलेट जोड़ना होगा:

 <?xml version="1.0" encoding="UTF-8"?> <t:template xmlns:t="http://nop.org/schemas/templating/core"> <t:head> <t:parameter name="actorInfo"/> <t:service name="actorsRoute" class="org.nop.actors.ActorsRoute"/> </t:head> <t:body> <html> <head> <title>A simple actors example</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> <script src="${actorsRoute.resource('actors.js')}" type="text/javascript"/> </head> <body> <div> <input type="text" id="argument"/> <button id="pingButton" type="button">Ping</button> </div> <div id="pingResult"/> <script> Pingable = {}; Pinger = {}; Pingable.ping = ["value", actorRef(Pinger)]; Pinger.pong = ["value"]; DefaultPinger = actor(function(elem) { this.elem = elem; }); DefaultPinger.prototype.pong = function(token) { var messageElem = document.createElement("div"); messageElem.textContent = token; this.elem.appendChild(messageElem); } var pinger = actor(new DefaultPinger( document.getElementById("pingResult"))); var remoting = new ActorRemoting("/actors/${actorInfo.sessionId}"); var pingable = remoting.importActor(Pingable, ${actorInfo.nodeId}, ${actorInfo.actorId}); remoting.start(); var argumentElem = document.getElementById("argument"); document.getElementById("pingButton").onclick = function() { pingable.ping(argumentElem.value, pinger); } </script> </body> </html> </t:body> </t:template> 

एक रेडी-टू-रन उदाहरण यहां डाउनलोड किया जा सकता है ।

अभिनेताओं पर शतरंज

यहां, सब कुछ स्पष्ट प्रतीत होता है: तीन अभिनेता खेल में भाग ले रहे हैं: दो खिलाड़ी और एक खेल का मैदान। अंतिम अभिनेता खिलाड़ियों की चालों की जाँच करता है और उन्हें एक दूसरे की चालों को सूचित करता है। तो ऐसे इंटरफेस के बारे में कोई लिख सकता है:

 @Actor public interface Board { void registerPlayer(Player player, PieceColor color); void move(Player player, BoardLocation source, BoardLocation destination); } 

 @Actor public interface Player { void moveRejected(); void moved(BoardLocation source, BoardLocation destination); } 

बोर्ड का कार्यान्वयन, जाहिर है, खिलाड़ी के लिए एक हटकर संदेश भेजता है अगर उसने गलत कदम उठाया या समय पर नहीं गया। स्थानांतरित किया गया संदेश दोनों खिलाड़ियों को भेजा जाता है। प्रतिद्वंद्वी की प्रगति की सूचना के रूप में, वॉकर को - इस कदम की पुष्टि के संकेत के रूप में, प्रतिद्वंद्वी को।

बस यह इंटरफ़ेस बहुत भोला बना है। चाल को बनाने वाला खिलाड़ी स्वयं इंगित करता है कि किसकी ओर से यह चाल चली गई है। एक हमलावर इसका उपयोग निडरता से कर सकता है। इसके अलावा, अगर, किसी कारण से, अभिनेता-खिलाड़ियों में से एक "गिर गया", तो उसके पास खेल की स्थिति को बहाल करने का कोई तरीका नहीं है। इसलिए, हम इन कमियों को दूर करने के लिए निम्नलिखित इंटरफेस लिखते हैं:

 @Actor public interface Board { void authorizePlayer(PlayerObserver observer, String key); } 

 @Actor public interface Player { void move(BoardLocation source, BoardLocation destination, PieceType promotedType); } 

 @Actor public interface PlayerObserver { void authorizationAccepted(PieceColor color, Player player); void authorizationRejected(); void moveRejected(); void boardStateChanged(BoardState state); void moved(BoardLocation source, BoardLocation destination); } 

तो यही हुआ। अब खिलाड़ी PlayerObserver इंटरफ़ेस के पीछे छिपा हुआ है। और खेल मैदान का प्रतिनिधित्व एक बोर्ड और एक खिलाड़ी द्वारा किया जाता है। खिलाड़ी एक विशिष्ट खिलाड़ी के लिए उपलब्ध खेल मैदान का एक प्रकार का पहलू है। खेल में प्रवेश करते हुए, अभिनेता-खिलाड़ी पासवर्ड के खेल क्षेत्र को सूचित करता है और खुद के लिए एक लिंक प्रसारित करता है। यह एक प्राधिकरण संदेश के रूप में खेल के मैदान से पुष्टि प्राप्त करता है। इसके अलावा, खेल से जुड़कर, अभिनेता को एक संदेश बोर्ड के रूप में पल में खेल के मैदान की स्थिति प्राप्त होती है।

ध्यान दें कि खिलाड़ी अभिनेता और बोर्ड अभिनेता दोनों को एक दूसरे के साथ राज्य साझा करना चाहिए। तो यह वास्तव में है, एनओपी इस का समर्थन करता है। हम कह सकते हैं कि यह एक ऐसा अभिनेता है जो विभिन्न कोणों से दिखाई देता है। यहाँ वास्तव में कैसा दिखता है AuthorizePlayer संदेश प्रसंस्करण

  @Override public void authorizePlayer(PlayerObserver observer, String key) { boolean matches = false; for (PlayerImpl player : players.values()) { if (player.token.equals(key)) { observer.authorizationAccepted(player.color, player); sendFullState(observer); player.setPlayerObserver(observer); updateObserverList(); matches = true; break; } } if (!matches) { observer.authorizationRejected(); } } private void sendFullState(PlayerObserver observer) { BoardState state = new BoardState(); //      . // ... observer.boardStateChanged(state); } 

यहां, खिलाड़ी पर्यवेक्षक को पास किया जाता है जबकि बोर्ड संदेश को संसाधित कर रहा है। क्योंकि खिलाड़ी को स्पष्ट रूप से एक अभिनेता नहीं बनाया गया था, फ्रेमवर्क स्वचालित रूप से इसे बना देगा, और साथ ही इसे बोर्ड में विलय कर देगा। वास्तव में, एक नया अभिनेता बनाने के लिए जिसमें दूसरों के साथ एक सामान्य राज्य नहीं है, यह स्पष्ट रूप से अभिनेता-श्राप का उपयोग करके इसे एक अभिनेता बनाने के लिए आवश्यक है।

पूर्ण बोर्ड / प्लेयर अभिनेता कोड यहां पाया जा सकता है ।

जावास्क्रिप्ट में एक भाग के लिए, अभिनेता इंटरफ़ेस का विवरण आवश्यक है। यहाँ यह कैसा दिखता है:

 Board = {}; Player = {}; PlayerObserver = {}; BoardLocation = { row : "value", column : "value" }; PieceState = { type : "value", color : "value", location : BoardLocation }; Move = { source : BoardLocation, destination : BoardLocation, piece : "value", capturedPiece : "value" }; BoardState = { moves : [Move], pieces : [PieceState] }; Board.authorizePlayer = [actorRef(PlayerObserver), "value"]; Player.move = [BoardLocation, BoardLocation]; PlayerObserver.authorizationAccepted = ["value", actorRef(Player)]; PlayerObserver.authorizationRejected = []; PlayerObserver.moveRejected = []; PlayerObserver.boardStateChanged = [BoardState]; PlayerObserver.moved = [BoardLocation, BoardLocation]; 

प्लेयरबर्स्वर कार्यान्वयन केवल पृष्ठ को फिर से दिखाता है जब सर्वर से संदेश आते हैं और खिलाड़ी को आंकड़ा स्थानांतरित करने पर सर्वर को संदेश भेजता है।

ब्राउज़र अभिनेता का पूर्ण कार्यान्वयन यहां उपलब्ध है ।

शतरंज का उदाहरण एक डेमो एप्लिकेशन के रूप में एनओपी फ्रेमवर्क के वितरण में शामिल है। एप्लिकेशन कोड / डेमो / शतरंज फ़ोल्डर में स्थित है। मैंने भी तैयार सेवा को उठाया।

लाभ

पारदर्शी संदेश प्राप्त करने में सक्षम होने के अलावा, nop.actors निम्नलिखित चीजें भी कर सकते हैं।

सबसे पहले, रूपरेखा पूरी तरह से मॉड्यूलर है। प्रक्रिया के भीतर अभिनेताओं के तंत्र का कार्यान्वयन है। प्रक्रिया के अंदर अभिनेताओं के शीर्ष पर बने दूरस्थ अभिनेताओं का कार्यान्वयन होता है, और यह कार्यान्वयन किसी भी परिवहन का उपयोग कर सकता है।

दूसरे, संस्करण 3.0 के सर्वलेट्स का उपयोग करके लंबे-पोल अनुरोधों के अतुल्यकालिक प्रसंस्करण। यदि 1000 क्लाइंट सर्वर से जुड़े हैं, तो इसका मतलब यह नहीं होगा कि यह 1000 धागे बनाएगा जो कुछ भी नहीं करते हैं।

तीसरा, सिस्टम स्वचालित रूप से डिस्क को खाली करने के लिए कुछ भी नहीं कर रहा है, मेमोरी को खाली करता है। इसके अलावा, किसी भी अभिनेता का जीवनकाल संभवतः अनंत है।