رسالة عرافة مشوهة عبر المقبس

Question

أحاول تمرير رسالة عرافة من خادم ج إلى عميل جافا.يعمل الاتصال.ولكن قيمة عرافة أن أحصل على عميل جافا يبدو أن إلحاق مع"فف".لماذا يحدث هذا?

في الجانب ج ، عندما أطبع بايت أريد أن أرسل (في عرافة) ، يبدو أنها موافق.

يرجى الاطلاع على الرمز أدناه:

سي سيرفر:

                    int datalen = 220;

                    /* create  outgoing message */
                    idx = 0;
                    en_outmsg[idx++] = FEB & 0xFF;
                    en_outmsg[idx++] = ENT & 0xFF;
                    en_outmsg[idx++] = CBA & 0xFF;
                    en_outmsg[idx++] = GRP & 0xFF;
                    en_outmsg[idx++] = OUTGOING & 0xFF;
                    en_outmsg[idx++] = (datalen & 0xFF00) >> 8;
                    en_outmsg[idx++] = datalen & 0xFF;

                    for(i= 0; i<39; i++){
                    printf("en_outmsg[%d] to send = %x\n",i, en_outmsg[i]);
                    }
                    en_outmsg[i+1] = '\n';


                    if (send(connected, en_outmsg, 40, 0) > 0)
                    {
                        printf("sending over\n");

                    }

عميل جافا:

    while( (bytes =dis.read(buffer, 0, 40)) != -1){
        for(int index=38; index >= 0; index--)  {           

                System.out.println("index ="+index);
                System.out.println("buffer ="+Integer.toHexString(buffer[index]));
        }
        System.out.println("bytes="+bytes); 
        len = 0;
        len |= buffer[5];
        len = len << 8;
        len |=  buffer[6];
        System.out.println("value of len= "+len);
    }

الناتج:قيمة لين= -36 المخزن المؤقت[5] = 0 المخزن المؤقت [6]= 0

تحديث

هنا هو بلدي الانتاج يريشارك (وهذا هو ما يدفع خادم ج إلى عميل جافا):

لاحظ أنه في الصف 5 "00 دس" يتوافق مع داتالين= 220 التي يجب تخزينها على هذا النحو في لين على عميل جافا.لذلك من الواضح أن هناك بعض الأخطاء على عميل جافا.كما ذكرت جميعا ، يمكنني استخدام عدد صحيح.توهيكسترينغ (((إنت)العازلة [فهرس]) و 0 إكس إف) للطباعة.ولكن أنا بحاجة لتخزين مجموعة بايت مع القيم عرافة الصحيحة.الرجاء المساعدة

0000  00 00 03 04 00 06 00 00  00 00 00 00 00 00 08 00   ........ ........
0010  45 00 00 5c b4 75 40 00  40 06 a0 ac c0 a8 b2 14   E..\.u@. @.......
0020  c0 a8 b2 14 09 60 b7 bb  fe bd 3a 2d fe 36 cc 8c   .....`.. ..:-.6..
0030  80 18 02 20 e5 c8 00 00  01 01 08 0a 00 04 8e 5f   ... .... ......._
0040  00 04 8e 5f 0a 01 01 16  01 00 dc 00 01 02 03 04   ..._.... ........
0050  05 06 07 08 09 0a 0b 0c  0d 0e 0f 2b 7e 15 16 28   ........ ...+~..(
0060  ae d2 a6 ab f7 15 88 09  cf 4f 3c d0               ........ .O<.    

Answer 1

يجب أن تكون خطوتك الأولى في هذه الحالة هي معرفة ما يتم إرساله "عبر السلك". إذا كنت قادرًا ، ففكر في استخدام wireshark أو tcpdump لمعرفة ما يتم نقله. بهذه الطريقة ، يمكنك معرفة ما لا يعمل كما هو متوقع. يمكن لكليهما مراقبة مآخذ التوصيل المرتبطة بعناوين IP المحلية بالإضافة إلى مآخذ الاسترجاع.

ولكن من مظهرها ، أوافق على وجود صدام موقّع / غير موقع.

إذا كان لديك هذا الناتج ، فسيكون مفيدًا في تحديد "من" المخطئ.

< تحديث:

كما ذكرنا سابقًا ، سترغب في إخفاء واستخدام أقل 8 بت فقط ويمكن القيام بذلك عن طريق: Genacodicetagpre

يمكنك إدخال هذا في شفرتك بطريقتين ، إحداهما من خلال وظيفة ثابتة بسيطة تستدعيها لكل بايت ، على سبيل المثال Genacodicetagpre

والآخر هو دالة مجمعة لـ DataInputStream.read () تقرأ البايت في مخزن مؤقت ، ثم تخفيها جميعًا. قد يبدو على النحو التالي: Genacodicetagpre

إذا اخترت الطريقة الأولى ، فقد ترغب في استدعاء mask () على أي قيمة [] للمخزن المؤقت تستخدمها. لذلك Genacodicetagpre سيكون

Genacodicetagpre

إذا اخترت الطريقة الثانية ، فيمكنك تغيير المخزن المؤقت من مصفوفة من نوع بايت إلى int:

Genacodicetagpre

ويمكن أن تقوم بتحديث حلقة while الخاصة بك إلى شيء مثل: Genacodicetagpre

ولكن هذا يقال ...

يعد الخيار الأفضل من أيٍّ من هذين الخيارين هو استخدام طريقة readUnsignedByte ل DataInputStream .

ستحتاج إلى سحب 40 بايت من الدفق في كل مرة بنفسك ، ولكن سيكون من الواضح أكثر بكثير ما كنت تفعله بدلاً من العبث. سيكون هذا هو النهج المفضل في رأيي.

Answer 2

وحدات البايت في جافا موقعة.لذا فإن كل قيمة تحتوي على مجموعة بت الأكثر أهمية هي قيمة سالبة.عندما يتم تحويلها إلى عدد صحيح يحدث عند استدعاء Integer.toHexString ، يتم تمديد الإشارة.لذلك إذا كان 10000000b فسيصبح 11111111111111111111111110000000b أو 0xFFFFFF80 بدلاً من 0x80.لأن هذه هي نفس القيمة السالبة في 32 بت.القيام به Genacodicetagpre

يجب إصلاحه

راجع للشغل ، جافا لا تحتوي على أنواع غير موقعة.

Answer 3

But the hex value that I get on Java client seems to be appended with "FF"

Integer.toHexString(buffer[index] & 0xFF ) سوف إصلاح مشكلتك.

Answer 4

تبدو وكأنها إشارة بت الانتشار.يبدو أن len ومتغيرات JAVA الأخرى موقعة عندما لا يجب ذلك.