इनपुट Buffer

Question

में इंडी टीसीपी क्लाइंट और दुष्ट बाइट आईपी के माध्यम से बाहरी मॉडेम/राउटर (उर्फ डिवाइस) से लिखने और पढ़ने के लिए कोड की निम्नलिखित कुछ पंक्तियों का उपयोग कर रहा हूं।

TCPClient.IOHandler.Write(MsgStr); 
TCPClient.IOHandler.InputBuffer.Clear; 
TCPClient.IOHandler.ReadBytes(Buffer, 10, True); 

MsgStr एक स्ट्रिंग प्रकार है जिसमें वह पाठ है जो मैं अपने डिवाइस पर भेज रहा हूं। बफर को टीआईडीबीट्स के रूप में घोषित किया गया है। मैं पुष्टि कर सकता हूं कि IOHandler.InputBufferIsEmpty रिटर्नबाइट्स को कॉल करने से पहले तुरंत लौटाता है।

मुझे उम्मीद है कि पहले 10 बाइट्स मेरे विशिष्ट दृष्टिकोण से बहुत विशिष्ट हो गए हैं, इसलिए मुझे अपनी स्ट्रिंग भेजने के बाद प्राप्त पहले 10 बाइट्स में दिलचस्पी है।

मुसीबत मैं कर रहा हूँ, जब कुछ उपकरणों के लिए बात कर रही है, पहली बाइट लौटे पहली बार मैं एक कनेक्शन की स्थापना के बाद एक स्ट्रिंग भेज दिया है मेरी बफर उत्पादन में एक दुष्ट (यादृच्छिक) बाइट डालता है। निम्नलिखित बाइट्स सही हैं।

जैसे 10 बाइट्स मैं हो सकता है उम्मीद कर रहा हूँ: # 6A1EF1090 # 3 लेकिन क्या मैं है # 6A1EF1090।। इस उदाहरण में मेरे पास एक पूर्ण स्टॉप है जहां एक नहीं होना चाहिए।

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

क्या कोई ऐसी चीज है जो मैं गलत तरीके से कर रहा हूं जिससे यह कारण हो सकता है - यह ध्यान में रखकर केवल पहली बार होता है जब मैं कनेक्शन स्थापित करने के बाद लिख रहा हूं?

धन्यवाद

संपादित

मैं डेल्फी 7 और इंडी 10.5.8

अद्यतन

ठीक उपयोग कर रहा हूँ। अधिक परीक्षण और देखने के बाद, मैं इस समाधान को खोजने के करीब नहीं हूं। मुझे दो मुख्य परिदृश्य मिल रहे हैं। 1 - पहली बाइट गायब और 2 - प्राप्त पैकेट की शुरुआत में "पेश" बाइट। TIdLogEvent और TIdLogDebug का उपयोग करके या तो गायब बाइट या प्रारंभिक पेश किए गए बाइट को उपयुक्त के रूप में दिखाएं। तो उपरोक्त मेरे रीडबाइट्स कथन लगातार दिखा रहा है कि इंडी का मानना ​​है कि (मेरी राय में)।

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

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

Answer 1

पिछले पैरामीटर (सच)

TCPClient.IOHandler.ReadBytes(Buffer, 10, True); 

पढ़ने का कारण बनता है।

यह आवश्यक है कि बफर का आकार और सामग्री पहले सही ढंग से स्थापित हो।

यदि पैरामीटर गलत है, तो बफर सामग्री बाइट्स की दी गई संख्या के लिए प्रतिस्थापित की जाएगी।

Answer 2

ReadBytes() बफर में दुष्ट बाइट्स इंजेक्षन नहीं है, इसलिए वहाँ केवल दो संभावनाएं मैं अभी दी सीमित जानकारी के बारे में सोच सकते हैं आपके द्वारा दिए गए हैं:

1. डिवाइस वास्तव में पर एक अतिरिक्त बाइट भेज रहा है प्रारंभिक कनेक्शन, जैसे mj2008 सुझाव दिया। यदि कोई पैकेट स्निफ़र इसका पता नहीं लगा रहा है, तो TIdTCPClient, जैसे TIdLogFile या TIdLogEvent पर इंडी के अपने TIdLog... घटकों को जोड़ने का प्रयास करें, यह सत्यापित करने के लिए कि TIdTCPClient वास्तव में सॉकेट से प्राप्त कर रहा है।

2. आपके पास एक ही समय में एक ही कनेक्शन से पढ़ने के लिए एक और थ्रेड है, InputBuffer दूषित। यहां तक ​​कि TIdTCPClient.Connected() पर एक कॉल भी पढ़ा जाएगा। यदि आप धागे का उपयोग कर रहे हैं, तो एक ही समय में एकाधिक धागे में पढ़ना न करें।