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

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

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

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

System Structure

2
Jerry Dodge 15 फरवरी 2012, 06:21

2 जवाब

सबसे बढ़िया उत्तर

प्रक्रियाओं के बीच संचार करता है, आप पाइप/मेलस्लॉट/सॉकेट का उपयोग कर सकते हैं, मुझे भी लगता है कि स्ट्रीम फ़ाइल भेजते समय साझा मेमोरी शायद सबसे कुशल तरीका है

1
horsley 15 फरवरी 2012, 06:35

मैंने इसे कई बार किया है, कई अलग-अलग कॉन्फ़िगरेशन में। मेरे लिए इसे आसान बनाने की कुंजी RemObjects SDK का उपयोग करना था जो संचार भाग का ख्याल रखता था। एक धागे के साथ जो इसकी स्थिति को नियंत्रित करता है, मेरे पास एक सर्वर या सेवा से एक कनेक्शन हो सकता है जो विश्वसनीय है, और स्थिति बाइट से कुछ भी स्थानांतरित कर सकता है कई मेगाबाइट डेटा स्थानांतरित करने के लिए (यह अनुशंसा की जाती है कि आप बड़े डेटा के लिए छोटे हिस्से का उपयोग करें ताकि कि आपके पास त्रुटियों और प्रवाह पर अधिक बारीक नियंत्रण है)। अब मेरे पास उच्च विश्वसनीयता टेम्पलेट्स का एक सेट है जिसे मैं आसानी से एक नई भिन्नता बनाने के लिए तैनात कर सकता हूं, और इसे बिना किसी परेशानी के नए फ़ंक्शन कॉल के साथ अपडेट किया जा सकता है (पहली चीज जो मैं करता हूं वह क्लाइंट और सर्वर के बीच संस्करणों पर बातचीत करता है ताकि वे जान सकें कि क्या वे समर्थन कर सकते हैं)। क्योंकि यह सब उच्च स्तर पर काम करता है, मेरा कोड सिर्फ "फ़ंक्शन कॉल" कर रहा है और इस बारे में कभी चिंता नहीं करता कि तार पर प्रारूप क्या है। इसी तरह मैं मूल तर्क को बदले बिना उनके बाइनरी प्रारूप से मानक SOAP या अन्य में स्विच कर सकता हूं। अंत में, कनेक्शन स्थानीय हो सकते हैं, उसी मशीन के लिए (मैं इसका उपयोग पृष्ठभूमि सेवा से बात करने वाले अंतिम उपयोगकर्ता ऐप्स के लिए करता हूं) या लैन या इंटरनेट पर एक मशीन के लिए। सभी एक ही कोड में।

1
mj2008 15 फरवरी 2012, 14:00