सेशन (कंप्यूटर विज्ञान): Difference between revisions
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
परिवहन प्रोटोकॉल के स्थितिे में जो औपचारिक सत्र परत (उदाहरण के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल) को लागू नहीं करते हैं या जहां आवेदन परत पर सत्र सामान्यतःपर बहुत ही कम रहते हैं (उदाहरण के लिए, एचटीटीपी), सत्र उच्च स्तरीय कार्यक्रम द्वारा बनाए रखा जाता है। एक्सचेंज किए जा रहे डेटा में परिभाषित विधि। उदाहरण के लिए, ब्राउज़र और दूरस्थ होस्ट के बीच एचटीटीपी एक्सचेंज में एक [[HTTP कुकी|एचटीटीपी कुकी]] सम्मिलित हो सकती है जो स्थिति की पहचान करती है, जैसे कि एक अद्वितीय [[सत्र आईडी]], उपयोगकर्ता की प्राथमिकताओं या प्राधिकरण स्तर के बारे में जानकारी। | परिवहन प्रोटोकॉल के स्थितिे में जो औपचारिक सत्र परत (उदाहरण के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल) को लागू नहीं करते हैं या जहां आवेदन परत पर सत्र सामान्यतःपर बहुत ही कम रहते हैं (उदाहरण के लिए, एचटीटीपी), सत्र उच्च स्तरीय कार्यक्रम द्वारा बनाए रखा जाता है। एक्सचेंज किए जा रहे डेटा में परिभाषित विधि। उदाहरण के लिए, ब्राउज़र और दूरस्थ होस्ट के बीच एचटीटीपी एक्सचेंज में एक [[HTTP कुकी|एचटीटीपी कुकी]] सम्मिलित हो सकती है जो स्थिति की पहचान करती है, जैसे कि एक अद्वितीय [[सत्र आईडी]], उपयोगकर्ता की प्राथमिकताओं या प्राधिकरण स्तर के बारे में जानकारी। | ||
एचटीटीपी/1.0 को वेब/एचटीटीपी सत्र के | एचटीटीपी/1.0 को वेब/एचटीटीपी सत्र के समय केवल एक ही अनुरोध और प्रतिक्रिया की अनुमति देने के बारे में सोचा गया था। प्रोटोकॉल संस्करण एचटीटीपी/1.1 ने [[कॉमन गेटवे इंटरफ़ेस]] (सीजीआई ) को पूरा करके इसमें सुधार किया, जिससे वेब सत्र को बनाए रखना और एचटीटीपी कुकीज़ और फ़ाइल अपलोड का समर्थन करना आसान हो गया। | ||
अधिकांश क्लाइंट-सर्वर सत्र [[ट्रांसपोर्ट परत]] द्वारा बनाए जाते हैं - सत्र के लिए कनेक्शन। चूंकि वेब/एचटीटीपी सत्र का प्रत्येक लेन-देन चरण अलग कनेक्शन बनाता है। चरणों के बीच सत्र की निरंतरता बनाए रखने के लिए सत्र आईडी की आवश्यकता होती है। सत्र आईडी [[गतिशील वेब पेज]] के <A HREF> या <FORM> लिंक के भीतर एम्बेड की जाती है | अधिकांश क्लाइंट-सर्वर सत्र [[ट्रांसपोर्ट परत]] द्वारा बनाए जाते हैं - सत्र के लिए कनेक्शन। चूंकि वेब/एचटीटीपी सत्र का प्रत्येक लेन-देन चरण अलग कनेक्शन बनाता है। चरणों के बीच सत्र की निरंतरता बनाए रखने के लिए सत्र आईडी की आवश्यकता होती है। सत्र आईडी [[गतिशील वेब पेज]] के <A HREF> या <FORM> लिंक के भीतर एम्बेड की जाती है जिससे इसे वापस सीजीआई को पास किया जा सके। सीजीआई तब लेन-देन चरणों के बीच सत्र की निरंतरता सुनिश्चित करने के लिए सत्र आईडी का उपयोग करता है। कनेक्शन-प्रति-चरण का फायदा यह है कि यह कम बैंडविड्थ (मॉडेम) कनेक्शन पर अच्छी तरह से काम करता है। | ||
== सॉफ्टवेयर कार्यान्वयन == | == सॉफ्टवेयर कार्यान्वयन == | ||
टीसीपी सत्र सामान्यतःपर [[बाल प्रक्रिया]]ओं और/या थ्रेड (कंप्यूटर विज्ञान) का उपयोग करके सॉफ़्टवेयर में कार्यान्वित किए जाते हैं, जहां कंप्यूटर द्वारा सत्र स्थापित करने या उसमें सम्मिलित होने पर नई प्रक्रिया या थ्रेड बनाया जाता है। एचटीटीपी सत्र सामान्यतःपर प्रति सत्र थ्रेड का उपयोग करके लागू नहीं किए जाते हैं, | टीसीपी सत्र सामान्यतःपर [[बाल प्रक्रिया]]ओं और/या थ्रेड (कंप्यूटर विज्ञान) का उपयोग करके सॉफ़्टवेयर में कार्यान्वित किए जाते हैं, जहां कंप्यूटर द्वारा सत्र स्थापित करने या उसमें सम्मिलित होने पर नई प्रक्रिया या थ्रेड बनाया जाता है। एचटीटीपी सत्र सामान्यतःपर प्रति सत्र थ्रेड का उपयोग करके लागू नहीं किए जाते हैं, किन्तु डेटाबेस के माध्यम से प्रत्येक सत्र की स्थिति के बारे में जानकारी होती है। कई प्रक्रियाओं या थ्रेड्स के साथ लाभ सॉफ्टवेयर की जटिल जटिलता है, क्योंकि प्रत्येक थ्रेड [[वस्तु (कंप्यूटर विज्ञान)]] है जिसका अपना इतिहास और इनकैप्सुलेटेड चर है। सिस्टम संसाधनों के स्थितिे में हनी बड़ा ओवरहेड है, और यदि सिस्टम पुनरारंभ होता है तो सत्र बाधित हो सकता है। | ||
जब कोई क्लाइंट सर्वर के क्लस्टर में किसी भी सर्वर से जुड़ सकता है, तो सर्वर को सत्र स्थिति बनाए रखने के | जब कोई क्लाइंट सर्वर के क्लस्टर में किसी भी सर्वर से जुड़ सकता है, तो सर्वर को सत्र स्थिति बनाए रखने के समय निरंतरता बनाए रखने में विशेष समस्या का सामना करना पड़ता है। क्लाइंट को सत्र की अवधि के लिए या तो उसी सर्वर पर निर्देशित किया जाना चाहिए, या सर्वर को साझा फ़ाइल सिस्टम या डेटाबेस के माध्यम से सर्वर-साइड सत्र की जानकारी संचारित करनी चाहिए। अन्यथा, क्लाइंट सत्र प्रारंभू करने वाले सर्वर से अलग सर्वर से फिर से कनेक्ट हो सकता है, जो समस्या उत्पन्न करेगा जब नए सर्वर के पास पुराने सर्वर की संग्रहीत स्थिति तक पहुंच नहीं होगी। | ||
== सर्वर-साइड वेब सत्र == | == सर्वर-साइड वेब सत्र == | ||
सर्वर-साइड सत्र आसान और कुशल होते हैं, | सर्वर-साइड सत्र आसान और कुशल होते हैं, किन्तु लोड-बैलेंसिंग/उच्च-उपलब्धता सिस्टम के संयोजन के साथ संभालना कठिनाई हो सकता है और बिना स्टोरेज वाले कुछ एम्बेडेड सिस्टम में उपयोग करने योग्य नहीं होते हैं। लोड-बैलेंसिंग समस्या को साझा भंडारण का उपयोग करके या क्लस्टर में प्रत्येक क्लाइंट और एकल सर्वर के बीच मजबूर पीयरिंग लागू करके हल किया जा सकता है, चूंकि यह सिस्टम दक्षता और लोड वितरण से समझौता कर सकता है। | ||
मास-स्टोरेज के बिना सिस्टम में सर्वर-साइड सत्र का उपयोग करने का विधि सत्र डेटा के भंडारण के लिए रैम के हिस्से को आरक्षित करना है। यह विधि सीमित संख्या में ग्राहकों के साथ सर्वर के लिए लागू होती है (उदाहरण के लिए एक समय में एक से अधिक क्लाइंट के लिए दुर्लभ या अस्वीकृत पहुंच वाले राउटर या एक्सेस प्वाइंट)। | मास-स्टोरेज के बिना सिस्टम में सर्वर-साइड सत्र का उपयोग करने का विधि सत्र डेटा के भंडारण के लिए रैम के हिस्से को आरक्षित करना है। यह विधि सीमित संख्या में ग्राहकों के साथ सर्वर के लिए लागू होती है (उदाहरण के लिए एक समय में एक से अधिक क्लाइंट के लिए दुर्लभ या अस्वीकृत पहुंच वाले राउटर या एक्सेस प्वाइंट)। | ||
| Line 50: | Line 50: | ||
मानव-कंप्यूटर इंटरैक्शन में, सत्र प्रबंधन [[कंप्यूटर प्रणाली]] के साथ बातचीत के सत्रों में उपयोगकर्ता की गतिविधि का ट्रैक रखने की प्रक्रिया है। | मानव-कंप्यूटर इंटरैक्शन में, सत्र प्रबंधन [[कंप्यूटर प्रणाली]] के साथ बातचीत के सत्रों में उपयोगकर्ता की गतिविधि का ट्रैक रखने की प्रक्रिया है। | ||
[[डेस्कटॉप वातावरण]] में विशिष्ट सत्र प्रबंधन कार्यों में यह ट्रैक रखना सम्मिलित है कि कौन से एप्लिकेशन खुले हैं और प्रत्येक एप्लिकेशन ने कौन से दस्तावेज़ खोले हैं, | [[डेस्कटॉप वातावरण]] में विशिष्ट सत्र प्रबंधन कार्यों में यह ट्रैक रखना सम्मिलित है कि कौन से एप्लिकेशन खुले हैं और प्रत्येक एप्लिकेशन ने कौन से दस्तावेज़ खोले हैं, जिससे उपयोगकर्ता द्वारा लॉग आउट करने और बाद में लॉग इन करने पर उसी स्थिति को पुनर्स्थापित किया जा सके। किसी वेबसाइट के लिए, ss | ||
=== डेस्कटॉप सत्र प्रबंधन === | === डेस्कटॉप सत्र प्रबंधन === | ||
| Line 68: | Line 68: | ||
ऐसी स्थितियों में जहां कई वेब सर्वरों को सत्र स्थिति का ज्ञान साझा करना चाहिए (जैसा कि [[कंप्यूटर क्लस्टर]] वातावरण में सामान्य है) वेब सर्वर सॉफ़्टवेयर चलाने वाले क्लस्टर नोड्स के बीच सत्र जानकारी साझा की जानी चाहिए। क्लस्टर में नोड्स के बीच सत्र स्थिति साझा करने के तरीकों में सम्मिलित हैं: सदस्य नोड्स को मल्टीकास्टिंग सत्र जानकारी (इस तकनीक के उदाहरण के लिए [[JGroups|जेग्रुप्स]] देखें), वितरित साझा मेमोरी या [[मेमोरी वर्चुअलाइजेशन]] का उपयोग करके पार्टनर नोड के साथ सत्र जानकारी साझा करना, नोड्स के बीच सत्र जानकारी साझा करना नेटवर्क सॉकेट, साझा फ़ाइल सिस्टम पर सत्र जानकारी संग्रहीत करना जैसे [[वितरित फ़ाइल सिस्टम]] या वैश्विक फ़ाइल सिस्टम, या डेटाबेस में क्लस्टर के बाहर सत्र जानकारी संग्रहीत करना। | ऐसी स्थितियों में जहां कई वेब सर्वरों को सत्र स्थिति का ज्ञान साझा करना चाहिए (जैसा कि [[कंप्यूटर क्लस्टर]] वातावरण में सामान्य है) वेब सर्वर सॉफ़्टवेयर चलाने वाले क्लस्टर नोड्स के बीच सत्र जानकारी साझा की जानी चाहिए। क्लस्टर में नोड्स के बीच सत्र स्थिति साझा करने के तरीकों में सम्मिलित हैं: सदस्य नोड्स को मल्टीकास्टिंग सत्र जानकारी (इस तकनीक के उदाहरण के लिए [[JGroups|जेग्रुप्स]] देखें), वितरित साझा मेमोरी या [[मेमोरी वर्चुअलाइजेशन]] का उपयोग करके पार्टनर नोड के साथ सत्र जानकारी साझा करना, नोड्स के बीच सत्र जानकारी साझा करना नेटवर्क सॉकेट, साझा फ़ाइल सिस्टम पर सत्र जानकारी संग्रहीत करना जैसे [[वितरित फ़ाइल सिस्टम]] या वैश्विक फ़ाइल सिस्टम, या डेटाबेस में क्लस्टर के बाहर सत्र जानकारी संग्रहीत करना। | ||
यदि सत्र की जानकारी को क्षणिक, अस्थिर डेटा माना जाता है जो लेन-देन की गैर-अस्वीकृति के लिए आवश्यक नहीं है और इसमें डेटा सम्मिलित नहीं है जो अनुपालन ऑडिटिंग के अधीन है (उदाहरण के लिए यू.एस. में, [[स्वास्थ्य बीमा सुवाह्यता और जवाबदेही अधिनियम]] और सरबनेस-ऑक्सले देखें दो कानूनों के उदाहरण के लिए अधिनियम जो अनुपालन ऑडिटिंग की आवश्यकता होती है) तो सत्र की जानकारी संग्रहीत करने की किसी भी विधि का उपयोग किया जा सकता है। चूंकि, यदि सत्र की जानकारी ऑडिट अनुपालन के अधीन है, तो सत्र भंडारण, प्रतिकृति और क्लस्टरिंग के लिए उपयोग की जाने वाली विधि पर विचार किया जाना चाहिए। | यदि सत्र की जानकारी को क्षणिक, अस्थिर डेटा माना जाता है जो लेन-देन की गैर-अस्वीकृति के लिए आवश्यक नहीं है और इसमें डेटा सम्मिलित नहीं है जो अनुपालन ऑडिटिंग के अधीन है (उदाहरण के लिए यू.एस. में, [[स्वास्थ्य बीमा सुवाह्यता और जवाबदेही अधिनियम|स्वास्थ्य बीमा सुवाह्यता और उत्तरदेही अधिनियम]] और सरबनेस-ऑक्सले देखें दो कानूनों के उदाहरण के लिए अधिनियम जो अनुपालन ऑडिटिंग की आवश्यकता होती है) तो सत्र की जानकारी संग्रहीत करने की किसी भी विधि का उपयोग किया जा सकता है। चूंकि, यदि सत्र की जानकारी ऑडिट अनुपालन के अधीन है, तो सत्र भंडारण, प्रतिकृति और क्लस्टरिंग के लिए उपयोग की जाने वाली विधि पर विचार किया जाना चाहिए। | ||
सेवा-उन्मुख आर्किटेक्चर में, एक्सटेंसिबल मार्कअप लैंग्वेज ([[XML|एक्सएमएल]]) संदेशों के साथ निर्मित सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल या [[SOAP|सोप]] संदेशों का उपयोग उपभोक्ता अनुप्रयोगों द्वारा वेब सर्वरों को सत्र बनाने के लिए किया जा सकता है। | सेवा-उन्मुख आर्किटेक्चर में, एक्सटेंसिबल मार्कअप लैंग्वेज ([[XML|एक्सएमएल]]) संदेशों के साथ निर्मित सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल या [[SOAP|सोप]] संदेशों का उपयोग उपभोक्ता अनुप्रयोगों द्वारा वेब सर्वरों को सत्र बनाने के लिए किया जा सकता है। | ||
=== [[एसएमएस]] पर सत्र प्रबंधन === | === [[एसएमएस]] पर सत्र प्रबंधन === | ||
जैसे एचटीटीपी [[स्टेटलेस प्रोटोकॉल]] है, वैसे ही एसएमएस भी है। जैसे ही 1999 में प्रतिद्वंद्वी नेटवर्कों पर एसएमएस इंटरऑपरेबल हो गया,<ref>{{citation |publisher=CTIA |title=InterCarrier Messaging Guidelines |url=http://files.ctia.org/pdf/Inter-Carrier_SMS_Guidelines_V3.1_As_Adopted_May_2012-final.pdf |access-date=2018-06-02}}</ref> और टेक्स्ट मैसेजिंग ने संचार का सर्वव्यापी वैश्विक रूप बनने की दिशा में अपनी | जैसे एचटीटीपी [[स्टेटलेस प्रोटोकॉल]] है, वैसे ही एसएमएस भी है। जैसे ही 1999 में प्रतिद्वंद्वी नेटवर्कों पर एसएमएस इंटरऑपरेबल हो गया,<ref>{{citation |publisher=CTIA |title=InterCarrier Messaging Guidelines |url=http://files.ctia.org/pdf/Inter-Carrier_SMS_Guidelines_V3.1_As_Adopted_May_2012-final.pdf |access-date=2018-06-02}}</ref> और टेक्स्ट मैसेजिंग ने संचार का सर्वव्यापी वैश्विक रूप बनने की दिशा में अपनी प्रारंभआत की,<ref>Hppy bthdy txt! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm 3 December 2002.</ref> विभिन्न उद्यम व्यावसायिक उद्देश्यों के लिए एसएमएस चैनल का उपयोग करने में रुचि रखते हैं। प्रारंभिक सेवाओं के लिए सत्र प्रबंधन की आवश्यकता नहीं थी क्योंकि वे केवल एकतरफा संचार थे (उदाहरण के लिए, 2000 में, मोबाइल फोन#फीचर्स)। आज, इन अनुप्रयोगों को संक्षिप्त संदेश सेवा या एप्लीकेशन-टू-पर्सन (ए2पी) एसएमएस| एप्लीकेशन-टू-पीयर (ए2पी) संदेश के रूप में संदर्भित किया जाता है, जो [[लघु संदेश पीयर-टू-पीयर]]|पीयर-टू-पीयर (पी2पी) से अलग है। संदेश। इंटरैक्टिव उद्यम अनुप्रयोगों के विकास के लिए सत्र प्रबंधन की आवश्यकता होती है, किन्तु क्योंकि एसएमएस जीएसएम मानकों द्वारा परिभाषित स्टेटलेस प्रोटोकॉल है,<ref>GSM Doc 28/85 "Services and Facilities to be provided in the GSM System" rev2, June 1985</ref> आरंभिक कार्यान्वयनों को अंत-उपयोगकर्ताओं द्वारा आदेश और सेवा पहचानकर्ताओं को मैन्युअल रूप से अंकित करने के द्वारा [[ग्राहक की ओर]] नियंत्रित किया गया था। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 13:08, 1 February 2023
विशेष रूप से कंप्यूटर विज्ञान और कंप्यूटर नेटवर्क में, एक सत्र समय-सीमांकित दो-तरफा लिंक है, इंटरनेट प्रोटोकॉल सूट में व्यावहारिक (अपेक्षाकृत उच्च) परत है। टीसीपी/आईपी प्रोटोकॉल दो या दो से अधिक संचार उपकरणों के बीच इंटरैक्टिव अभिव्यक्ति और सूचना विनिमय को सक्षम करता है। या समाप्त - चाहे वे कंप्यूटर हों, स्वचालन हों, या लाइव सक्रिय उपयोगकर्ता हों (लॉगिन सत्र देखें)। निश्चित समय पर सत्र स्थापित किया जाता है, और फिर कुछ बाद के बिंदु पर 'टूट डाउन' - समाप्त कर दिया जाता है। स्थापित संचार सत्र में प्रत्येक दिशा में एक से अधिक संदेश सम्मिलित हो सकते हैं। सत्र सामान्यतःपर स्टेटफुल होता है, जिसका अर्थ है कि कम से कम संवाद करने वाले पक्ष को वर्तमान स्थिति की जानकारी रखने और संवाद करने में सक्षम होने के लिए सत्र इतिहास के बारे में जानकारी सहेजने की आवश्यकता होती है, जैसा कि स्टेटलेस सर्वर संचार के विपरीत होता है, जहां संचार में स्वतंत्र अनुरोध-प्रतिक्रिया सम्मिलित होती है। प्रतिक्रियाओं के साथ।
कनेक्शन-उन्मुख संचार करने के लिए स्थापित सत्र बुनियादी आवश्यकता है। कनेक्शन रहित संचार मोड में संचारण के लिए सत्र भी बुनियादी कदम है। चूंकि, कोई भी यूनिडायरेक्शनल ट्रांसमिशन सत्र को परिभाषित नहीं करता है।[1]
संचार परिवहन को अनुप्रयोग स्तर पर, सत्र स्तर पर या ओएसआई मॉडल में परिवहन स्तर पर प्रोटोकॉल और सेवाओं के भाग के रूप में लागू किया जा सकता है।
- आवेदन परत उदाहरण:
- एचटीटीपी सत्र, जो व्यक्तिगत आगंतुकों के साथ जानकारी को संबद्ध करने की अनुमति देता है
- एक टेलनेट दूरस्थ लॉगिन सत्र
- सत्र परत उदाहरण:
- एक सत्र आरंभ प्रोटोकॉल (एसआईपी) आधारित इंटरनेट फोन कॉल
- परिवहन परत उदाहरण:
- एक ट्रांसमिशन कंट्रोल प्रोटोकॉल सत्र, जो टीसीपी वर्चूअल सर्किट, टीसीपी कनेक्शन या स्थापित टीसीपी इंटरनेट सॉकेट का पर्याय है।
परिवहन प्रोटोकॉल के स्थितिे में जो औपचारिक सत्र परत (उदाहरण के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल) को लागू नहीं करते हैं या जहां आवेदन परत पर सत्र सामान्यतःपर बहुत ही कम रहते हैं (उदाहरण के लिए, एचटीटीपी), सत्र उच्च स्तरीय कार्यक्रम द्वारा बनाए रखा जाता है। एक्सचेंज किए जा रहे डेटा में परिभाषित विधि। उदाहरण के लिए, ब्राउज़र और दूरस्थ होस्ट के बीच एचटीटीपी एक्सचेंज में एक एचटीटीपी कुकी सम्मिलित हो सकती है जो स्थिति की पहचान करती है, जैसे कि एक अद्वितीय सत्र आईडी, उपयोगकर्ता की प्राथमिकताओं या प्राधिकरण स्तर के बारे में जानकारी।
एचटीटीपी/1.0 को वेब/एचटीटीपी सत्र के समय केवल एक ही अनुरोध और प्रतिक्रिया की अनुमति देने के बारे में सोचा गया था। प्रोटोकॉल संस्करण एचटीटीपी/1.1 ने कॉमन गेटवे इंटरफ़ेस (सीजीआई ) को पूरा करके इसमें सुधार किया, जिससे वेब सत्र को बनाए रखना और एचटीटीपी कुकीज़ और फ़ाइल अपलोड का समर्थन करना आसान हो गया।
अधिकांश क्लाइंट-सर्वर सत्र ट्रांसपोर्ट परत द्वारा बनाए जाते हैं - सत्र के लिए कनेक्शन। चूंकि वेब/एचटीटीपी सत्र का प्रत्येक लेन-देन चरण अलग कनेक्शन बनाता है। चरणों के बीच सत्र की निरंतरता बनाए रखने के लिए सत्र आईडी की आवश्यकता होती है। सत्र आईडी गतिशील वेब पेज के <A HREF> या <FORM> लिंक के भीतर एम्बेड की जाती है जिससे इसे वापस सीजीआई को पास किया जा सके। सीजीआई तब लेन-देन चरणों के बीच सत्र की निरंतरता सुनिश्चित करने के लिए सत्र आईडी का उपयोग करता है। कनेक्शन-प्रति-चरण का फायदा यह है कि यह कम बैंडविड्थ (मॉडेम) कनेक्शन पर अच्छी तरह से काम करता है।
सॉफ्टवेयर कार्यान्वयन
टीसीपी सत्र सामान्यतःपर बाल प्रक्रियाओं और/या थ्रेड (कंप्यूटर विज्ञान) का उपयोग करके सॉफ़्टवेयर में कार्यान्वित किए जाते हैं, जहां कंप्यूटर द्वारा सत्र स्थापित करने या उसमें सम्मिलित होने पर नई प्रक्रिया या थ्रेड बनाया जाता है। एचटीटीपी सत्र सामान्यतःपर प्रति सत्र थ्रेड का उपयोग करके लागू नहीं किए जाते हैं, किन्तु डेटाबेस के माध्यम से प्रत्येक सत्र की स्थिति के बारे में जानकारी होती है। कई प्रक्रियाओं या थ्रेड्स के साथ लाभ सॉफ्टवेयर की जटिल जटिलता है, क्योंकि प्रत्येक थ्रेड वस्तु (कंप्यूटर विज्ञान) है जिसका अपना इतिहास और इनकैप्सुलेटेड चर है। सिस्टम संसाधनों के स्थितिे में हनी बड़ा ओवरहेड है, और यदि सिस्टम पुनरारंभ होता है तो सत्र बाधित हो सकता है।
जब कोई क्लाइंट सर्वर के क्लस्टर में किसी भी सर्वर से जुड़ सकता है, तो सर्वर को सत्र स्थिति बनाए रखने के समय निरंतरता बनाए रखने में विशेष समस्या का सामना करना पड़ता है। क्लाइंट को सत्र की अवधि के लिए या तो उसी सर्वर पर निर्देशित किया जाना चाहिए, या सर्वर को साझा फ़ाइल सिस्टम या डेटाबेस के माध्यम से सर्वर-साइड सत्र की जानकारी संचारित करनी चाहिए। अन्यथा, क्लाइंट सत्र प्रारंभू करने वाले सर्वर से अलग सर्वर से फिर से कनेक्ट हो सकता है, जो समस्या उत्पन्न करेगा जब नए सर्वर के पास पुराने सर्वर की संग्रहीत स्थिति तक पहुंच नहीं होगी।
सर्वर-साइड वेब सत्र
सर्वर-साइड सत्र आसान और कुशल होते हैं, किन्तु लोड-बैलेंसिंग/उच्च-उपलब्धता सिस्टम के संयोजन के साथ संभालना कठिनाई हो सकता है और बिना स्टोरेज वाले कुछ एम्बेडेड सिस्टम में उपयोग करने योग्य नहीं होते हैं। लोड-बैलेंसिंग समस्या को साझा भंडारण का उपयोग करके या क्लस्टर में प्रत्येक क्लाइंट और एकल सर्वर के बीच मजबूर पीयरिंग लागू करके हल किया जा सकता है, चूंकि यह सिस्टम दक्षता और लोड वितरण से समझौता कर सकता है।
मास-स्टोरेज के बिना सिस्टम में सर्वर-साइड सत्र का उपयोग करने का विधि सत्र डेटा के भंडारण के लिए रैम के हिस्से को आरक्षित करना है। यह विधि सीमित संख्या में ग्राहकों के साथ सर्वर के लिए लागू होती है (उदाहरण के लिए एक समय में एक से अधिक क्लाइंट के लिए दुर्लभ या अस्वीकृत पहुंच वाले राउटर या एक्सेस प्वाइंट)।
क्लाइंट-साइड वेब सत्र
क्लाइंट-साइड सत्र एचटीटीपी_cookie और क्रिप्टोग्राफ़िक तकनीकों का उपयोग सर्वर पर अधिक डेटा संग्रहीत किए बिना स्थिति को बनाए रखने के लिए करते हैं। डायनेमिक वेब पेज प्रस्तुत करते समय, सर्वर कुकी के रूप में क्लाइंट (वेब ब्राउज़र) को वर्तमान स्थिति डेटा भेजता है। क्लाइंट कुकी को स्मृति या डिस्क पर सहेजता है। प्रत्येक क्रमिक अनुरोध के साथ, क्लाइंट कुकी को सर्वर पर वापस भेजता है, और सर्वर उस विशिष्ट क्लाइंट के लिए एप्लिकेशन की स्थिति को याद रखने और उचित प्रतिक्रिया उत्पन्न करने के लिए डेटा का उपयोग करता है।
यह तंत्र कुछ संदर्भों में अच्छा काम कर सकता है; चूंकि, क्लाइंट पर संग्रहीत डेटा उपयोगकर्ता या सॉफ़्टवेयर द्वारा छेड़छाड़ करने के लिए असुरक्षित है जिसकी क्लाइंट कंप्यूटर तक पहुँच है। क्लाइंट-साइड सत्रों का उपयोग करने के लिए जहां गोपनीयता और अखंडता की आवश्यकता होती है, निम्नलिखित की गारंटी होनी चाहिए:
- गोपनीयता: सर्वर के अतिरिक्त कुछ भी सत्र डेटा की व्याख्या करने में सक्षम नहीं होना चाहिए।
- डेटा अखंडता: सर्वर के अतिरिक्त कुछ भी सत्र डेटा (गलती से या दुर्भावनापूर्ण रूप से) में हेरफेर नहीं करना चाहिए।
- प्रामाणिकता: सर्वर के अतिरिक्त कुछ भी वैध सत्र आरंभ करने में सक्षम नहीं होना चाहिए।
इसे पूरा करने के लिए, सर्वर को क्लाइंट को भेजने से पहले सत्र डेटा को एन्क्रिप्ट करने की आवश्यकता होती है, और किसी अन्य पार्टी द्वारा ऐसी जानकारी के संशोधन को क्रिप्टोग्राफ़िक माध्यमों से रोका जाना चाहिए।
कुकी का आकार छोटा होने पर प्रत्येक अनुरोध के साथ राज्य को आगे और आगे प्रसारित करना ही व्यावहारिक है। संक्षेप में, प्रत्येक वेब अनुरोध के लिए आवश्यक अतिरिक्त बैंडविड्थ के लिए क्लाइंट-साइड सत्र व्यापार सर्वर डिस्क स्थान। इसके अतिरिक्त, वेब ब्राउज़र कुकीज़ की संख्या और आकार को सीमित करते हैं जिन्हें वेब साइट द्वारा संग्रहीत किया जा सकता है। दक्षता में सुधार करने और अधिक सत्र डेटा की अनुमति देने के लिए, सर्वर कुकी बनाने से पहले डेटा को कंप्रेस कर सकता है, बाद में जब क्लाइंट द्वारा कुकी लौटाई जाती है तो इसे डीकंप्रेस कर सकता है।
एचटीटीपी सत्र टोकन
एक सत्र टोकन अद्वितीय पहचानकर्ता है जो वर्तमान इंटरैक्शन सत्र की पहचान करने के लिए सर्वर (कंप्यूटिंग) से क्लाइंट (कंप्यूटिंग) को उत्पन्न और भेजा जाता है। क्लाइंट सामान्यतःपर एचटीटीपी कुकी के रूप में टोकन को स्टोर और भेजता है और/या इसे गेट या पोस्ट प्रश्नों में पैरामीटर के रूप में भेजता है। सत्र टोकन का उपयोग करने का कारण यह है कि क्लाइंट को केवल पहचानकर्ता को संभालना होता है - सभी सत्र डेटा उस पहचानकर्ता से जुड़े सर्वर (सामान्यतःपर डेटाबेस में, जिसमें क्लाइंट की सीधी पहुंच नहीं होती है) पर संग्रहीत होती है। कुछ प्रोग्रामिंग भाषाएँ अपनी एचटीटीपी कुकी का नामकरण करते समय जिन नामों का उपयोग करती हैं, उनमें जेएसइएसएसआईओएनआईडी (जावा सर्वर पेज), पीएचपी एसइएसएसआईडी (पीएचपी ), सीजीआई एसइएसएसआईडी (कॉमन गेटवे इंटरफ़ेस), और एएसपीएसइएसएसआईओएनआईडी (सक्रिय सर्वर पेज) सम्मिलित हैं।
सत्र प्रबंधन
मानव-कंप्यूटर इंटरैक्शन में, सत्र प्रबंधन कंप्यूटर प्रणाली के साथ बातचीत के सत्रों में उपयोगकर्ता की गतिविधि का ट्रैक रखने की प्रक्रिया है।
डेस्कटॉप वातावरण में विशिष्ट सत्र प्रबंधन कार्यों में यह ट्रैक रखना सम्मिलित है कि कौन से एप्लिकेशन खुले हैं और प्रत्येक एप्लिकेशन ने कौन से दस्तावेज़ खोले हैं, जिससे उपयोगकर्ता द्वारा लॉग आउट करने और बाद में लॉग इन करने पर उसी स्थिति को पुनर्स्थापित किया जा सके। किसी वेबसाइट के लिए, ss
डेस्कटॉप सत्र प्रबंधन
डेस्कटॉप सेशन मैनेजर प्रोग्राम है जो डेस्कटॉप सेशन को सेव और रीस्टोर कर सकता है। डेस्कटॉप सत्र वर्तमान में चल रही सभी विंडो और उनकी वर्तमान सामग्री है। लिनक्स-आधारित सिस्टम पर सत्र प्रबंधन X सत्र प्रबंधक द्वारा प्रदान किया जाता है। माइक्रोसॉफ्ट विंडोज सिस्टम पर, सत्र प्रबंधक सबसिस्टम (एसएमएसएस.इएक्सइ) द्वारा सत्र प्रबंधन प्रदान किया जाता है; उपयोगकर्ता सत्र की कार्यक्षमता को थर्ड-पार्टी एप्लिकेशन जैसे कि जुड़वाँ खेल द्वारा बढ़ाया जा सकता है।
ब्राउज़र सत्र प्रबंधन
सत्र प्रबंधन वेब ब्राउज़र में विशेष रूप से उपयोगी है जहां उपयोगकर्ता सभी खुले पृष्ठों और सेटिंग्स को सहेज सकता है और उन्हें बाद की तारीख में या किसी भिन्न कंप्यूटर पर पुनर्स्थापित कर सकता है (डेटा पोर्टेबिलिटी देखें)।
सिस्टम या एप्लिकेशन क्रैश से पुनर्प्राप्त करने में सहायता के लिए, पृष्ठ और सेटिंग्स को अगले रन पर भी पुनर्स्थापित किया जा सकता है। गूगल क्रोम, मोज़िला फ़ायरफ़ॉक्स, इंटरनेट एक्स्प्लोरर, ओमनीवेब और ओपेरा (वेब ब्राउज़र) वेब ब्राउज़र के उदाहरण हैं जो सत्र प्रबंधन का समर्थन करते हैं। सत्र प्रबंधन को अधिकांशतः एचटीटीपी कुकी के अनुप्रयोग के माध्यम से प्रबंधित किया जाता है।
वेब सर्वर सत्र प्रबंधन
हाइपरटेक्स्ट परहस्त शिष्टाचार (एचटीटीपी) स्टेटलेस है। सत्र प्रबंधन वेब डेवलपर द्वारा स्टेटलेस एचटीटीपी प्रोटोकॉल सपोर्ट सेशन स्टेट बनाने के लिए उपयोग की जाने वाली तकनीक है। उदाहरण के लिए, उपयोगकर्ता को वेब सर्वर पर प्रमाणित कर दिए जाने के बाद, उपयोगकर्ता का अगला एचटीटीपी अनुरोध (गेट या पोस्ट) वेब सर्वर को उपयोगकर्ता के खाते और पासवर्ड के लिए फिर से पूछने का कारण नहीं बनना चाहिए। इसे पूरा करने के लिए उपयोग की जाने वाली विधियों की चर्चा के लिए एचटीटीपी कुकी और सत्र आईडी देखें
ऐसी स्थितियों में जहां कई वेब सर्वरों को सत्र स्थिति का ज्ञान साझा करना चाहिए (जैसा कि कंप्यूटर क्लस्टर वातावरण में सामान्य है) वेब सर्वर सॉफ़्टवेयर चलाने वाले क्लस्टर नोड्स के बीच सत्र जानकारी साझा की जानी चाहिए। क्लस्टर में नोड्स के बीच सत्र स्थिति साझा करने के तरीकों में सम्मिलित हैं: सदस्य नोड्स को मल्टीकास्टिंग सत्र जानकारी (इस तकनीक के उदाहरण के लिए जेग्रुप्स देखें), वितरित साझा मेमोरी या मेमोरी वर्चुअलाइजेशन का उपयोग करके पार्टनर नोड के साथ सत्र जानकारी साझा करना, नोड्स के बीच सत्र जानकारी साझा करना नेटवर्क सॉकेट, साझा फ़ाइल सिस्टम पर सत्र जानकारी संग्रहीत करना जैसे वितरित फ़ाइल सिस्टम या वैश्विक फ़ाइल सिस्टम, या डेटाबेस में क्लस्टर के बाहर सत्र जानकारी संग्रहीत करना।
यदि सत्र की जानकारी को क्षणिक, अस्थिर डेटा माना जाता है जो लेन-देन की गैर-अस्वीकृति के लिए आवश्यक नहीं है और इसमें डेटा सम्मिलित नहीं है जो अनुपालन ऑडिटिंग के अधीन है (उदाहरण के लिए यू.एस. में, स्वास्थ्य बीमा सुवाह्यता और उत्तरदेही अधिनियम और सरबनेस-ऑक्सले देखें दो कानूनों के उदाहरण के लिए अधिनियम जो अनुपालन ऑडिटिंग की आवश्यकता होती है) तो सत्र की जानकारी संग्रहीत करने की किसी भी विधि का उपयोग किया जा सकता है। चूंकि, यदि सत्र की जानकारी ऑडिट अनुपालन के अधीन है, तो सत्र भंडारण, प्रतिकृति और क्लस्टरिंग के लिए उपयोग की जाने वाली विधि पर विचार किया जाना चाहिए।
सेवा-उन्मुख आर्किटेक्चर में, एक्सटेंसिबल मार्कअप लैंग्वेज (एक्सएमएल) संदेशों के साथ निर्मित सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल या सोप संदेशों का उपयोग उपभोक्ता अनुप्रयोगों द्वारा वेब सर्वरों को सत्र बनाने के लिए किया जा सकता है।
एसएमएस पर सत्र प्रबंधन
जैसे एचटीटीपी स्टेटलेस प्रोटोकॉल है, वैसे ही एसएमएस भी है। जैसे ही 1999 में प्रतिद्वंद्वी नेटवर्कों पर एसएमएस इंटरऑपरेबल हो गया,[2] और टेक्स्ट मैसेजिंग ने संचार का सर्वव्यापी वैश्विक रूप बनने की दिशा में अपनी प्रारंभआत की,[3] विभिन्न उद्यम व्यावसायिक उद्देश्यों के लिए एसएमएस चैनल का उपयोग करने में रुचि रखते हैं। प्रारंभिक सेवाओं के लिए सत्र प्रबंधन की आवश्यकता नहीं थी क्योंकि वे केवल एकतरफा संचार थे (उदाहरण के लिए, 2000 में, मोबाइल फोन#फीचर्स)। आज, इन अनुप्रयोगों को संक्षिप्त संदेश सेवा या एप्लीकेशन-टू-पर्सन (ए2पी) एसएमएस| एप्लीकेशन-टू-पीयर (ए2पी) संदेश के रूप में संदर्भित किया जाता है, जो लघु संदेश पीयर-टू-पीयर|पीयर-टू-पीयर (पी2पी) से अलग है। संदेश। इंटरैक्टिव उद्यम अनुप्रयोगों के विकास के लिए सत्र प्रबंधन की आवश्यकता होती है, किन्तु क्योंकि एसएमएस जीएसएम मानकों द्वारा परिभाषित स्टेटलेस प्रोटोकॉल है,[4] आरंभिक कार्यान्वयनों को अंत-उपयोगकर्ताओं द्वारा आदेश और सेवा पहचानकर्ताओं को मैन्युअल रूप से अंकित करने के द्वारा ग्राहक की ओर नियंत्रित किया गया था।
यह भी देखें
- एचटीटीपीएस के
- आराम
- सत्र आईडी
- सत्रीकरण
- सत्र निर्धारण
- सत्र विषाक्तता
संदर्भ
- ↑ Sessionless-oriented protocol and session-oriented protocol
- ↑ InterCarrier Messaging Guidelines (PDF), CTIA, retrieved 2018-06-02
- ↑ Hppy bthdy txt! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm 3 December 2002.
- ↑ GSM Doc 28/85 "Services and Facilities to be provided in the GSM System" rev2, June 1985
