2011-06-12 6 views
5

के साथ ऑब्जेक्ट भेजना मैं वर्तमान में विजुअल स्टूडियो 2010 में परीक्षण कर रहा हूं। मैंने क्लाइंट और सर्वर बनाया जो दोनों UdpClient से कनेक्ट होंगे।UdpClient C#

मैं क्लाइंट से सर्वर पर एक ऑब्जेक्ट भेजना चाहता हूं। ऑब्जेक्ट को बाइट्स में बदलने और इसे ऑब्जेक्ट में बदलने के लिए मेरे पास दो विधियां हैं। अब, जब मैं अपने आवेदन का परीक्षण करता हूं तो मैं इसे सर्वर

पर प्राप्त एक ऑब्जेक्ट में वापस परिवर्तित नहीं कर सकता। मेरा सर्वर देखता है कि ऑब्जेक्ट प्राप्त होता है और इसे बाइट से ऑब्जेक्ट में परिवर्तित करने का प्रयास करता है लेकिन इससे कोई त्रुटि मिलती है।

System.Runtime.Serialization.SerializationException was unhandled Message=Unable to find assembly 

यह ठीक लग रहा है, क्योंकि दोनों अनुप्रयोगों के लिए एक अलग नाम स्थान में रहे हैं ...

ये मेरी तरीकों कन्वर्ट करने के लिए कर रहे हैं; क्लाइंट और सर्वर दोनों पर

public byte[] ToBytes() { 
     using (MemoryStream stream = new MemoryStream()) { 
      BinaryFormatter formatter = new BinaryFormatter(); 
      formatter.Serialize(stream, this); 

      stream.Position = 0; 

      byte[] byteRij = new byte[1024]; 

      stream.Read(byteRij, 0, (int)stream.Length); 

      return byteRij; 
     } 
    } 

    public static Datagram ToDatagram(byte[] rij) { 
     using (MemoryStream stream = new MemoryStream()) { 
      stream.Write(rij, 0, rij.Length); 

      stream.Position = 0; 

      BinaryFormatter formatter = new BinaryFormatter(); 
      return (Datagram)formatter.Deserialize(stream); 
     } 
    } 

मैं इसे कैसे हल कर सकता हूं? अग्रिम धन्यवाद

+1

आपकी 'ToBytes()' विधि सही ढंग से काम नहीं करेगी, धारावाहिक रूप 1024 बाइट से बड़ा है। आप ['ToArray()' विधि] (http://msdn.microsoft.com/en-us/library/system.io.memorystream.toarray.aspx) का उपयोग क्यों नहीं करते? – svick

उत्तर

3

आपको कक्षा पुस्तकालय परियोजना में क्रमबद्ध सभी वर्गों को रखने की आवश्यकता है। सर्वर और क्लाइंट दोनों में उस लाइब्रेरी का प्रयोग करें।

यह भी ध्यान दें कि यूडीपी विश्वसनीय नहीं है। इस बात की कोई गारंटी नहीं है कि आपके संदेश बिल्कुल आते हैं।

+0

ध्यान दें कि यह केवल एक बाइनरीफॉर्मेटर आवश्यकता है। आपको अधिकांश अन्य धारावाहिकों के लिए इसकी आवश्यकता नहीं है। –

+0

हां, मैंने सोचा कि मुझे कक्षा पुस्तकालय बनाना होगा। यह समझ आता है। इसके अलावा, मैं सिर्फ यह जानने के लिए यूडीपी का उपयोग कर रहा हूं कि मेरे पास कौन से विकल्प हैं। धन्यवाद! – kendepelchin

1

आपको असंतुष्ट निर्भरता के साथ समस्याएं आ रही हैं। यह विभिन्न नामस्थानों के कारण हो सकता है या बाहरी घटक को क्रमबद्ध करने की कोशिश कर रहा है, जो सर्वर पर स्थापित नहीं है।

कहें: आप MyApp1.MyFoo प्रकार की वस्तु भेजते हैं।
कक्षा MyFoo आपके सर्वर में भी परिभाषित किया गया है, लेकिन MyApp2.MyFoo (जो काफी मूर्ख है और इसका मतलब है कि आपको अपना डिज़ाइन ठीक करना है)। सर्वर को पता नहीं है कि MyApp1.MyFoo की ऑब्जेक्ट कैसे बनाएं, क्योंकि यह पता लगाने के लिए पर्याप्त स्मार्ट नहीं है कि उसके पास इस वर्ग को भी परिभाषित किया गया है, लेकिन MyApp2.MyFoo नाम दिया गया है।

आपको समान नामस्थानों का उपयोग करना चाहिए। यही वह है जो वे हैं। इसके अलावा, वे हैंडलिंग निर्भरताओं को आसान बनाते हैं। और MyApp.ServerMyApp.Client से बात कर अच्छा लग रहा है;)।

मुझे आशा है कि आपको बिंदु मिल जाएगा।

3

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

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

उदाहरण के लिए:

[ProtoContract] 
public class Foo { 
    [ProtoMember(1)] 
    public string X {get;set;} 
    [ProtoMember(2)] 
    public int Y {get;set;} 
} 

और फिर बस ProtoBuf.Serializer.Serialize (धारा, वस्तु) का उपयोग डेटा लिखने के लिए।

यदि आपको आवश्यकता हो तो आप बिना किसी विशेषता के काम भी कर सकते हैं, थोड़ा अधिक सेटअप लेता है, लेकिन अधिक नहीं।