काॅमेट प्रोग्रामिंग

From Vigyanwiki

काॅमेट प्रोग्रामिंग वेब अनुप्रयोग ऐसा प्रारूप है जिसमें लंबे समय से आयोजित होने वाले एचटीटीपीS पेज को वेब सर्वर द्वारा विभिन्न वेब ब्राउज़र के लिए तकनीकी रूप से डेटा को पुश करने की अनुमति देता है, इसके बिना ब्राउज़र को स्पष्ट रूप से अनुरोध किया जाता हैं।[1][2] काॅमेट ऐसा शब्द है, जिसमें इस अंतःक्रिया को प्राप्त करने के लिए कई तकनीकों को सम्मिलित किया गया है। ये सभी विधियाँ गैर-डिफ़ॉल्ट प्लगइन्स के अतिरिक्त ब्राउज़रों में डिफ़ॉल्ट रूप से सम्मिलित सुविधाओं पर निर्भर करती हैं, जैसे कि जावास्क्रिप्ट इसका उत्तम उदाहरण हैं। इस प्रकार काॅमेट का दृष्टिकोण वर्ल्ड वाइड वेब फंक्शन से भिन्न है, जिसमें ब्राउज़र समय में पूर्ण वेब पेज का अनुरोध करता है।[3]

वेब विकास में काॅमेट तकनीकों का उपयोग सामूहिक तकनीकों के लिए निओलिज़्म के रूप में काॅमेट शब्द के उपयोग से पहले का है। इस प्रकार काॅमेट सहित कई अन्य नामों जैसे अजाक्स पुश,[4][5] रिवर्स अजाक्स,[6] टू-वे-वेब,[7] एचटीटीपी स्ट्रीमिंग,[7] और एचटीटीपी पुश[8] से जाना जाता है।[9] इस प्रकार कॉमेट शब्द संक्षिप्त शब्द नहीं है, अपितु एलेक्स रसेल ने अपने 2006 के ब्लॉग पोस्ट कॉमेट: लो लेटेंसी डेटा फॉर द ब्राउजर में बनाया गया था।[10] वर्तमान समय के कुछ वर्षों में, वेबसॉकेट और सर्वर-भेजे गए कार्यक्रमों के मानकीकरण और व्यापक समर्थन ने काॅमेट प्रारूप को अप्रचलित कर दिया है।

इतिहास

प्रारंभिक जावा एप्लेट्स

जावा एप्लेट्स को ब्राउज़रों में एम्बेड करने की क्षमता के अनुसार मार्च 1996 में नेटस्केप नेविगेटर 2.0 के साथ प्रारंभ किया गया था।[11] जिसके द्वारा प्रारंभिक प्रसारण नियंत्रण प्रोटोकॉल के लिए सॉकेट का उपयोग करके दोनो दिशाओं से निरंतर संचार को संभव बनाया गया था,[12] इस प्रकार ब्राउज़र और सर्वर के बीच संचार करने के लिए इसका उपयोग किया जाता हैं। यह सॉकेट तब तक ओपेन रह सकता है जब ब्राउज़र एप्लेट को होस्ट करने वाले डाक्यूमेंट पर उपलब्ध रहते हैं। इसके अतिरिक्त ईवेंट सूचनाएं किसी भी प्रारूप में भेजी जा सकती हैं, इसके अनुसार टेक्स्ट या बाइनरी और एप्लेट द्वारा डिकोड किया गया हैं।

सर्वप्रथम ब्राउज़र-टू-ब्राउज़र संचार प्रारूप

ब्राउज़र-टू-ब्राउज़र संचार का उपयोग करने वाला पहला एप्लिकेशन टैंगो इंटरएक्टिव था,[13] इस प्रकार 1996-98 में नॉर्थईस्ट पैरेलल आर्किटेक्चर सेंटर (एनपीएसी) में सिराकस यूनिवर्सिटी में डार्पा फंडिंग का उपयोग करके लागू किया गया था। इसके अनुसार टैंगो संरचना को सिरैक्यूज़ विश्वविद्यालय द्वारा पेटेंट कराया गया है।[14] इस प्रकार दूरस्थ शिक्षा उपकरण के रूप में टैंगो प्रारूप का बड़े पैमाने पर उपयोग किया गया है।[15] कोलैब वर्क्स द्वारा इस प्रारूप का व्यावसायीकरण किया गया है और संयुक्त राज्य अमेरिका के रक्षा विभाग में दर्जन या इतने ही कमान और नियंत्रण और प्रशिक्षण अनुप्रयोगों में उपयोग किया गया है।.

सर्वप्रथम काॅमेट अनुप्रयोग

काॅमेट कार्यान्वयन का पहला सेट 2000 से पहले का है,[16] जिसे पुशलेट्स, लाइट स्ट्रीमर, और नो नाओ परियोजनाओं के साथ प्रदर्शित किया गया था। इस प्रकार पुशलेट्स, जस्ट वैन डेन ब्रौएके द्वारा बनाया गया प्रारूप सबसे पहले उपयोग किया गया था[17] इस प्रकार ओपेन स्रोत कार्यान्वयन के लिए पुशलेट सर्वर-साइड जावा सर्वलेट्स और क्लाइंट-साइड जावास्क्रिप्ट लाइब्रेरी पर आधारित थे। जिसके कारण बैंग नेटवर्क – नेटस्केप के सह-संस्थापक मार्क आंद्रेसेन द्वारा समर्थित सिलिकॉन वैली स्टार्ट-अप के पास संपूर्ण वेब के लिए रीयल-टाइम पुश मानक बनाने का भरपूर वित्तपोषित प्रयास था।[18] इस प्रकार अप्रैल 2001 में, चिप मॉर्निंगस्टार ने जावा-आधारित (J2SE) वेब सर्वर विकसित करना प्रारंभ कर दिया था, जो इसके परिणामस्वरूप दो एचटीटीपी सॉकेट का उपयोग करने में सक्षम थे, इसके द्वारा डिज़ाइन किए गए कस्टम एचटीटीपी सर्वर और डगलस क्रॉकफोर्ड द्वारा डिज़ाइन किए गए क्लाइंट के बीच दो संचार चैनलों को ओपेन रखता था, जून 2001 तक कार्यशील डेमो सिस्टम अस्तित्व में आया था। जिसके परिणामस्वरूप सर्वर और क्लाइंट ने मैसेजिंग प्रारूप का उपयोग किया जिसे क्रॉकफोर्ड के सुझाव के बाद स्टेट सॉफ्टवेयर, इंक. के संस्थापकों ने जेसाॅन के रूप में बनाने के लिए सहमति दी थी। इस प्रकार संपूर्ण सिस्टम, क्लाइंट लाइब्रेरी, मैसेजिंग फॉर्मेट जिसे जेसाॅन और सर्वर के रूप में जाना जाता है, स्टेट एप्लिकेशन फ्रेमवर्क बन गया, जिसके कुछ भागों को सन माइक्रोसिस्टम, Amazon.com, ईडीएस और वोक्सवैगेन द्वारा बेचा और उपयोग किया गया था।

मार्च 2006 में, सॉफ्टवेयर इंजीनियर एलेक्स रसेल ने अपने निजी ब्लॉग पर पोस्ट में काॅमेट शब्द को चयनित किया।[19] इस नये शब्द अजाक्स (प्रोग्रामिंग) अजाक्स (क्लीन्ज़र) और काॅमेट (क्लीन्ज़र) दोनों संयुक्त राज्य अमेरिका में आम घरेलू क्लीनर होने पर प्रदर्शित होता था। [20][21][22]

2006 में, कुछ अनुप्रयोगों ने उन तकनीकों को व्यापक दर्शकों के सामने प्रस्तुत किया था: मीबो के बहु-प्रोटोकॉल वेब-आधारित चैट एप्लिकेशन ने उपयोगकर्ताओं को एओएल इंस्टेंट मैसेंजर, याहू! ब्राउज़र के माध्यम से मैसेंजर, और एमएसएन मैसेंजर चैट प्लेटफॉर्म, गूगल ने जीमेल लगीं में वेब-आधारित चैट को जोड़ा, जाॅट स्पाट, गूगल द्वारा अधिग्रहित होने के बाद से स्टार्टअप, ने काॅमेट-आधारित वास्तविक समय सहयोगी डाॅक्यूमेंट के संपादन का निर्माण किया था।[23] इस प्रकार से प्राप्त नए काॅमेट वेरिएंट बनाए गए थे, जैसे कि जावा-आधारित आईसीई फेसेज जावा सर्वर फेसेज फ्रेमवर्क हैं, चूंकि इस प्रकार अजाक्स पुश शब्द को उपयोग करते हैं,[5] इस प्रकार के अन्य पहले के जावा-एप्लेट आधारित ट्रांसपोर्ट का उपयोग करते थे, जो मुख्य रूप से शुद्ध-जावास्क्रिप्ट कार्यान्वयन के अतिरिक्त स्विच किए गए थे।[24]

कार्यान्वयन

काॅमेट अनुप्रयोग वर्ल्ड वाइड वेब फंक्शन या पेज से पेज के लिए वेब प्रारूप और पारंपरिक कंप्यूटर विज्ञान की सीमाओं को समाप्त करने का प्रयास करते हैं, सर्वर और के बीच निरंतर या लंबे समय तक चलने वाले एचटीटीपी कनेक्शन का उपयोग करके दो-तरफा निरंतर बातचीत की प्रस्तुत करते हैं। चूंकि इस प्रकार ब्राउज़र और प्रॉक्सी को सर्वर ईवेंट को ध्यान में रखकर नहीं बनाया गया है, इसलिए इसे प्राप्त करने के लिए कई तकनीकें विकसित की गई हैं, जिनमें से प्रत्येक के अलग-अलग लाभ और कमियां हैं। इस प्रकार इसकी सबसे बड़ी बाधा हाइपरटेक्स्ट से जुड़ी 1.1 विनिर्देश है, जो इस विनिर्देश को यह बताता है कि ग्राहकों को कई कनेक्शन ओपेन करते समय रूढ़िवादी होने के लिए प्रोत्साहित करता है।[25] इसलिए, वास्तविक समय की घटनाओं के लिए कनेक्शन ओपेन रखने से ब्राउज़र की उपयोगिता पर ऋणात्मक प्रभाव पड़ता है: पिछले अनुरोध के परिणामों की प्रतीक्षा करते समय ब्राउज़र को नया अनुरोध भेजने से रोका जा सकता है, उदाहरण के लिए इमेजेस की श्रृंखला इसका प्रमुख उदाहरण हैं। इस प्रकार वास्तविक समय की जानकारी के लिए अलग होस्ट का नाम बनाकर इसे हल किया जा सकता है, जो भौतिक सर्वर के लिए उपनाम है। यह रणनीति डोमेन शार्डिंग का अनुप्रयोग है।

काॅमेट को लागू करने के विशिष्ट तरीके दो प्रमुख श्रेणियों स्ट्रीमिंग और लांग में आते हैं।

स्ट्रीमिंग

स्ट्रीमिंग काॅमेट का उपयोग करने वाला एप्लिकेशन वेब ब्राउज़र से सभी कॉमेट घटना (कंप्यूटिंग) के लिए सर्वर पर सतत कनेक्शन को ओपेन करता है। इस प्रकार निरंतर सर्वर के नये ईवेंट को भेजता है, तो इन घटनाओं को ग्राहक की ओर से नियंत्रित और व्याख्यायित किया जाता है, जिसमें कोई भी पक्ष कनेक्शन बंद नहीं करता है।[3]

स्ट्रीमिंग काॅमेट को पूरा करने की विशिष्ट तकनीकों में निम्नलिखित सम्मिलित हैं:

हिडन आईफ्रेम

डायनेमिक वेब एप्लिकेशन के लिए मौलिक तकनीक छिपे हुए एचटीएमएल एलिमेंट को फ्रेम्स एचटीएमएल एलिमेंट के लिए इनलाइन फ्रेम, जो वेबसाइट को एचटीएमएल डाक्यूमेंट को दूसरे के अंदर एम्बेड करने की अनुमति देता है जो इसका उपयोग करता है। इस प्रकार यह हिडेन आईफ्रेम चुनकेड ट्रांसफर एन्कोडिंग ब्लॉक के रूप में भेजा जाता है, जो इसे असीमित रूप से लंबे समय तक घोषित करता है, जो कभी-कभी या सदैव इसके लिए फ्रेम किया जाता है। जैसे ही इस प्रकार की घटनाएं होती हैं, जो इस प्रकार आईफ्रेम को धीरे-धीरे भर देता है, जिसके फलस्वरूप script टैग, जिसमें ब्राउज़र में निष्पादित होने वाली जावास्क्रिप्ट सम्मिलित हो जाती है। क्योंकि ब्राउज़र एचटीएमएल पृष्ठों को वृद्धिशील रूप से प्रस्तुत करते हैं, प्रत्येक script टैग प्राप्त होते ही निष्पादित किया जाता है। कुछ ब्राउज़रों को पार्सिंग और निष्पादन प्रारंभ करने से पहले विशिष्ट न्यूनतम डाक्यूमेंट आकार की आवश्यकता होती है, जिसे प्रारंभ में 1-2 kB पैडिंग स्पेस भेजकर प्राप्त किया जा सकता है।[26]

आई फ्रेम्स पद्धति का लाभ यह है कि यह प्रत्येक सामान्य ब्राउज़र में कार्य करती है। इस तकनीक के दो डाउनसाइड विश्वसनीय त्रुटि प्रबंधन पद्धति की कमी है, और इस प्रकार अनुरोध कॉलिंग प्रक्रिया की स्थिति को ट्रैक करने की असंभवता है।[26]

एक्सएमएल एचटीटीपी रिक्वेस्ट

एक्सएमएल एचटीटीपी रिक्वेस्ट एक्सएचआर ऑब्जेक्ट, ब्राउज़र-सर्वर संचार के लिए अजाक्स अनुप्रयोगों द्वारा उपयोग किया जाने वाला उपकरण, एक्सएचआर प्रतिक्रिया के लिए कस्टम डेटा प्रारूप उत्पन्न करके और ब्राउज़र का उपयोग करके प्रत्येक ईवेंट को पार्स करके सर्वर-ब्राउज़र कॉमेट मैसेजिंग के लिए सेवा में दबाया जा सकता है, इसके फलस्वरूप साइड जावास्क्रिप्ट, केवल ब्राउज़र फायरिंग पर भरोसा करते हुए onreadystatechange कॉलबैक हर बार यह नया डेटा प्राप्त करता है।

लांग पोलिंग के साथ अजाक्स का उपयोग

उपरोक्त स्ट्रीमिंग ट्रांसपोर्ट में से कोई भी ऋणात्मक साइड-इफेक्ट के बिना सभी आधुनिक ब्राउज़रों में कार्य नहीं करता है। यह काॅमेट डेवलपर्स को ब्राउज़र के आधार पर उनके बीच स्विच करने, कई जटिल स्ट्रीमिंग ट्रांसपोर्ट को लागू करने के लिए मजबूर करता है। इस प्रकार इसके परिणामस्वरूप इस प्रकार की कई काॅमेट अनुप्रयोग लांग पोलिंग का उपयोग करते हैं, जो कि ब्राउज़र पक्ष पर लागू करना आसान है, और एक्सएचआर का समर्थन करने वाले प्रत्येक ब्राउज़र में कम से कम कार्य करता है। जैसा कि नाम से पता चलता है, लांग पोलिंग के लिए क्लाइंट को किसी ईवेंट (या ईवेंट के सेट) के लिए सर्वर को पोल करने की आवश्यकता होती है। इस प्रकार ब्राउज़र सर्वर के लिए अजाक्स-शैली का अनुरोध करता है, जो तब तक ओपेन रहता है जब तक सर्वर के पास ब्राउज़र को भेजने के लिए नया डेटा नहीं होता है, जो ब्राउज़र को पूर्ण प्रतिक्रिया में भेजा जाता है। जिसके बाद की घटनाओं को प्राप्त करने के लिए ब्राउज़र नया लांग पोलिंग अनुरोध प्रारंभ करता है। [rfc:6202 आईईटीएफ आरएफसी 6202 लॉन्ग पोलिंग और द्विदिश एचटीटीपी में स्ट्रीमिंग के उपयोग के लिए ज्ञात विवाद और सर्वोत्तम अभ्यास] लंबे पोलिंग और एचटीटीपी स्ट्रीमिंग की तुलना करता है।

लांग पोलिंग को पूरा करने के लिए विशिष्ट तकनीकों में निम्नलिखित सम्मिलित हैं:

एक्स एमएलएचटीटीपी लांग पोलिंग का अनुरोध करें

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

स्क्रिप्ट टैग लंबे समय तक पोलिंग

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

आइफ्रेम या एक्स एमएलएचटीटीपीरिक्वेस्ट ऑब्जेक्ट के विपरीत, script टैग किसी भी यूनिफॉर्म रिसोर्स पहचानकर्ता पर इंगित किए जा सकते हैं, और प्रतिक्रिया में जावास्क्रिप्ट कोड को वर्तमान एचटीएमएल डाक्यूमेंट में निष्पादित किया जाएगा। यह सम्मिलित दोनों सर्वरों के लिए संभावित सुरक्षा के खतरे उत्पन्न करता है, चूंकि जेसाॅन पी का उपयोग करके डेटा प्रदाता मुख्य रूप से हमारे इस स्थिति में, काॅमेट सर्वर के लिए उत्पन्न होने वाले इस खतरे से बचा जा सकता है।

गतिशील रूप से निर्माण करके लांग पोलिंग काॅमेट परिवहन बनाया जा सकता है, इस प्रकार script एलिमेंट, और उनके स्रोत को काॅमेट सर्वर के स्थान पर सेट करना, जो इस प्रकार उसके पेलोड के रूप में कुछ घटना के साथ जावास्क्रिप्ट (या जेसाॅनपी) को वापस भेजता है। हर बार जब स्क्रिप्ट अनुरोध पूरा हो जाता है, तो ब्राउज़र नया ब्राउज़र ओपेन करता है, ठीक उसी प्रकार जैसे एक्सएचआर लॉन्ग पोलिंग केस में होता है। क्रॉस-डोमेन कार्यान्वयन की अनुमति देते हुए भी इस पद्धति का क्रॉस-ब्राउज़र होने का लाभ है।[27]

विकल्प

ब्राउज़र-देशी प्रौद्योगिकियां काॅमेट शब्द में निहित हैं। गैर-पोलिंग एचटीटीपी संचार को बेहतर बनाने के प्रयास कई पक्षों से आए हैं:

  • वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप (WHATWG) द्वारा तैयार किया गया एचटीएमएल 5 ड्राफ्ट विनिर्देश कथित सर्वर-भेजे गए ईवेंट को निर्दिष्ट करता है,[28] जो इस प्रकार नए जावास्क्रिप्ट इंटरफ़ेस को परिभाषित करता है EventSource और नया एमआईएमई प्रकार text/event-stream. Server-sent_events#Web_browsers में यह तकनीक सम्मिलित है।
  • एचटीएमएल 5 वेब स्ट्रोक एपीआई वर्किंग ड्राफ्ट सर्वर के साथ निरंतर कनेक्शन बनाने और संदेश प्राप्त करने के लिए विधि निर्दिष्ट करता है onmessage वापस कॉल करें।[29]
  • डोजो फाउंडेशन की ओर से बेयक्‍स प्रोटोकॉल। यह ब्राउज़र-विशिष्ट ट्रांसपोर्ट को जगह में छोड़ देता है, और ब्राउज़र और सर्वर के बीच संचार के लिए उच्च-स्तरीय प्रोटोकॉल को परिभाषित करता है, जिसका उद्देश्य क्लाइंट-साइड जावास्क्रिप्ट कोड को कई काॅमेट सर्वरों के साथ पुन: उपयोग करने की अनुमति देता है, और इस प्रकार उसी काॅमेट सर्वर को संचार करने की अनुमति देता है। एकाधिक क्लाइंट-साइड जावास्क्रिप्ट कार्यान्वयन के साथ बिना इसके उपयोग किए प्रकाशित/सदस्यता प्रारूप पर आधारित है, इसलिए बेयुक्स का समर्थन करने वाले सर्वर में अंतर्निहित प्रकाशित/सदस्यता है।[30]
  • एक्सएमपीपी मानक फाउंडेशन द्वारा बॉश (प्रोटोकॉल) प्रोटोकॉल किया जाता हैं। यह दो तुल्यकालिक एचटीटीपी कनेक्शन का उपयोग करके ब्राउज़र और सर्वर के बीच द्विदिश धारा का अनुकरण करता है।
  • डगलस क्रॉकफ़ोर्ड द्वारा प्रस्तावित जेसाॅन रिक्वेस्ट ऑब्जेक्ट, एक्सएचआर ऑब्जेक्ट का विकल्प होगा।[31]
  • प्लगइन्स का उपयोग, जैसे कि जावा एप्लेट्स एडोब फ्लैश जो मुख्य रूप से फ्लैश अनुप्रयोगों के लिए डेटा स्ट्रीमिंग के लिए रीयल-टाइम मैसेजिंग प्रोटोकॉल प्रोटोकॉल का उपयोग करता हैं। इस प्रकार से उपयुक्त प्लगइन के साथ सभी ब्राउज़रों में समान रूप से कार्य करने का लाभ मिलता है, और इस प्रकार एचटीटीपी कनेक्शन पर भरोसा करने की आवश्यकता नहीं है, अपितु प्लगइन को स्थापित करने की आवश्यकता की हानि नहीं होती हैं
  • इस प्रकार गूगल ने घोषणा की कि[32] गूगल ऐप इंजन के लिए नया चैनल एपीआई,[33] ब्राउजर पर क्लाइंट जावास्क्रिप्ट लाइब्रेरी की सहायता से कॉमेट जैसी एपीआई को लागू करना। इस एपीआई को बहिष्कृत कर दिया गया है। [34]

यह भी देखें

संदर्भ

  1. Krill, Paul (September 24, 2007). "AJAX गठबंधन मैशअप को पहचानता है". InfoWorld. Retrieved 2010-10-20.
  2. Crane, Dave; McCarthy, Phil (October 13, 2008). Comet and Reverse Ajax: The Next-Generation Ajax 2.0. Apress. ISBN 978-1-59059-998-3.
  3. 3.0 3.1 Gravelle, Rob. "Comet Programming: Using Ajax to Simulate Server Push". Webreference.com. Archived from the original on 2010-10-18. Retrieved 2010-10-20.
  4. Egloff, Andreas (2007-05-05). Ajax Push (a.k.a. Comet) with Java Business Integration (JBI) (Speech). JavaOne 2007, San Francisco, California: Sun Microsystems, Inc. Retrieved 2008-06-10.{{cite speech}}: CS1 maint: location (link)
  5. 5.0 5.1 "Ajax Push". ICEfaces.org. Retrieved 2014-10-23.
  6. Crane, Dave; McCarthy, Phil (July 2008). Comet and Reverse Ajax: The Next Generation Ajax 2.0. Apress. ISBN 1-59059-998-5.
  7. 7.0 7.1 Mahemoff, Michael (June 2006). "Web Remoting". Ajax Design Patterns. O'Reilly Media. pp. 19, 85. ISBN 0-596-10180-5.
  8. Double, Chris (2005-11-05). "More on Ajax and server push". Different ways of doing server push. Retrieved 2008-05-05.
  9. Nesbitt, Bryce (2005-11-01). "The Slow Load Technique/Reverse AJAX". Simulating Server Push in a Standard Web Browser. Archived from the original on 2006-02-08. Retrieved 2008-05-06.
  10. Russell, Alex (2006-03-04). "Comet: Low Latency Data for the Browser". Retrieved 2014-11-02.
  11. "नेटस्केप.कॉम". Archived from the original on November 15, 1996. Retrieved 2017-08-16.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  12. "java.net.Socket (Java 2 Platform SE v1.4.2)" Archived May 19, 2009, at the Wayback Machine
  13. Beca, Lukasz (1997). "TANGO - a Collaborative Environment for the World-Wide Web". Syracuse University SURFACE. Northeast Parallel Architecture Center, College of Engineering and Computer Science. Retrieved 27 February 2016.
  14. Podgorny, Marek; Beca, Lukasz; Cheng, Gang; Fox, Geoffrey C.; Jurga, Tomasz; Olszewski, Konrad; Sokolowski, Piotr; Walczak, Krzysztof; PL (June 20, 2000), United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions, retrieved 2016-02-27
  15. Baer, Troy (1999). "Experiences with Using TANGO Interactive in a Distributed Workshop" (PDF). CEWES Major Shared Resource Center. CEWES MSRC/PET TR/99-21. Retrieved 27 February 2016.
  16. "धूमकेतु दैनिक: धूमकेतु और धक्का प्रौद्योगिकी". Archived from the original on 2007-11-13. Retrieved 2007-12-15.
  17. Just van den Broecke (1 March 2000). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 1 August 2014.
  18. Borland, John (2001-04-01). "Will the "refresh" button become obsolete?". CNET Networks. Retrieved 2008-07-22.
  19. एलेक्स रसेल (3 मार्च 2006)। "धूमकेतु: ब्राउज़र के लिए कम विलंबता डेटा Archived 2008-08-12 at the Wayback Machine”। एलेक्स रसेल का ब्लॉग। 29 नवंबर 2007 को पुनःप्राप्त।
  20. K. Taft, Darryl (2006-05-12). "Microsoft ने AJAX टूल सेट से धूमकेतु को स्क्रब किया". eWEEK.com. Retrieved 2008-07-21.
  21. Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon
  22. Enterprise Comet & Web 2.0 Live Presentation Archived 2008-05-20 at the Wayback Machine
  23. Dion Almaer (29 September 2005). “Jotspot Live: Live, group note-taking” (interview with Abe Fettig). Ajaxian. Retrieved 15 December 2007.
    Matt Marshall (15 December 2006). “Renkoo launches event service — in time to schedule holiday cocktails”. Venture Beat. Retrieved 15 December 2007.
  24. Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 February 2008.
  25. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, section 6.4. IETF. Retrieved 2014-07-29
  26. 26.0 26.1 Holdener III, Anthony T. (January 2008). "Page Layout with Frames that Aren't". Ajax: The Definitive Guide. O'Reilly Media. p. 320. ISBN 0-596-52838-8.
  27. 27.0 27.1 Flanagan, David (2006-08-17). "13.8.4 Cross-Site Scripting". JavaScript the Definitive Guide. The Definitive Guide. O'Reilly Media. p. 994. ISBN 0-596-10199-6.
  28. Ian Hickson, ed. (2007-10-27). "6.2 Server-sent DOM events". HTML 5 - Call For Comments. WHATWG. Retrieved 2008-10-07.
  29. Hickson, Ian (2009-04-23). "The WebSocket API". W3C. Retrieved 2009-07-21.
  30. Alex Russell; et al. (2007). "बेयक्‍स प्रोटोकॉल - बायक्‍यूम 1.0ड्राफ्ट1।". Dojo Foundation. Retrieved 2007-12-14.
  31. Crockford, Douglas (2006-04-17). "JSONRequest Duplex". An alternative to XMLHttpRequest for long lasting server initiated push of data. Retrieved 2008-05-05.
  32. App, The. (2010-12-02) Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released. Googleappengine.blogspot.com. Retrieved on 2014-04-12.
  33. Paul, Ryan. (2010-12-06) App Engine gets Streaming API and longer background tasks. Ars Technica. Retrieved on 2014-04-12.
  34. "पैकेज com.google.appengine.api.channel". Google. 2019-11-16. Retrieved 2020-04-30. This API has been deprecated.


बाहरी संबंध

  • "Comet Daily". Archived from the original on 2008-01-04. Retrieved 2007-11-29. Comet Daily provides information about Comet techniques.*