Loading ...
Sorry, an error occurred while loading the content.
 

Re: Problems communicating with servents

Expand Messages
  • cogumbreiro@hotmail.com
    Out of sync? I did read the payload, and that s why i wrote that some of them had a payload (not the msg) length of 1400 that s huge and it can t be of a ping
    Message 1 of 15 , Aug 4, 2001
      Out of sync? I did read the payload, and that's why i wrote that some
      of them had a payload (not the msg) length of 1400 that's huge and it
      can't be of a ping reply (or can it). Do you think that my socket is
      putting 2 (or more) msgs together?
      I use Ms winsosk activex control, shouldn't i be using it? Is that
      what's causing the misread? (I have also the socket wrench control
      but i don't use it, should i use it?)
      My read data is simple, i just get the byte from the msg that
      correspond to the type and then decode the get the payload lenght
      (using len() )
      > This looks like you are out of sync. Note that pings can have a
      >payload, so read the payload length field of pings.

      Thanx i didn't knew that! Thnx!!!! I thought each msg you sent should
      have a new guid, but now i understand the whole concept. Great tip!
      > Guid should not be optional. A pong should only be sent in response
      >to a ping, and with the same guid as the ping. This might be the
      >reason you are being disconnected.

      I already do that, thx anywhay
      > A tip: When you test your client, run another client(BearShare,
      >LimeWire, 0.56 or whichever) on you machine, and connect to that
      >one. Then you know that you are not disconnected because the remote
      >host is busy.

      I greatly thank you by your reply, it really helped me!
      Best regards

      _____________
      Tiago Cogumbreiro
    • cogumbreiro@hotmail.com
      I ve changed the Pong function, yet the same thing happens, i connect to the servent, I ping the servent it replies with a pong and then floods me with pings
      Message 2 of 15 , Aug 4, 2001
        I've changed the Pong function, yet the same thing happens, i connect
        to the servent, I ping the servent it replies with a pong and
        then "floods" me with pings and unknown type msgs (including
        constantly the type # 24) and then closes the socket.
        What's wrong?
        __________
        Tiago Cogumbreiro
      • Tor Klingberg
        ... 0x01 is the hexadecimal value 01. You can use the windows calculator to convert it to a decimal (normal) number. The different payload descriptors are
        Message 3 of 15 , Aug 4, 2001
          > Could you explain me what's that "0x01" i had alot of problems
          > discovering wich value each of them would correspond to. Thanx
          > (sorry 'bout this newbie question, but if you never ask, you'll never
          > know, right? ^_^)

          0x01 is the hexadecimal value 01. You can use the windows calculator to convert it to a decimal (normal) number. The different payload descriptors are 0x00=0, 0x01=1, 0x40=64, 0x80=128, 0x81=129

          > Do you think that my socket is putting 2 (or more) msgs together?

          Yes, it is very common that you receive two or more gnutella messages from the same Winsock.getdata(). A single gnutella message may even be split up in two blocks, so you need to cache unfinished messages until you have the entire message.

          > I've changed the Pong function, yet the same thing happens, i connect
          > to the servent, I ping the servent it replies with a pong and
          > then "floods" me with pings and unknown type msgs (including
          > constantly the type # 24) and then closes the socket.
          > What's wrong?

          I think you are reading the bytes the wrong way. I think the 24 comes from that the default gnutella port is 6346, in hex 0x18CA. 0x18 is 24 in decimal. http://www.clip2.com/GnutellaProtocol04.pdf is a good reference if haven't read it already.

          --------------------------------------
          Tor Klingberg
          tor.klingberg@...
        • Brown Tiger
          ... Sorry? I thought they suppose to have no payload? T __________________________________________________ Do You Yahoo!? Make international calls for as low
          Message 4 of 15 , Aug 4, 2001
            --- Tor Klingberg <tor.klingberg@...> wrote:
            >> Note that pings
            > can have a payload, so read the payload length field
            > of pings.
            >

            Sorry? I thought they suppose to have no payload?

            T

            __________________________________________________
            Do You Yahoo!?
            Make international calls for as low as $.04/minute with Yahoo! Messenger
            http://phonecard.yahoo.com/
          • cogumbreiro@hotmail.com
            I ll check that, thanx for the tip! Maybe when my app reacts to a misunderstood ping it feedsback with pong an then the host servent closes my conn, could
            Message 5 of 15 , Aug 4, 2001
              I'll check that, thanx for the tip! Maybe when my app reacts to a
              misunderstood "ping" it feedsback with pong an then the host servent
              closes my conn, could this happen?
              > Yes, it is very common that you receive two or more gnutella
              >messages from the same Winsock.getdata(). A single gnutella message
              >may even be split up in two blocks, so you need to cache unfinished
              >messages until you have the entire message.

              Ok, now I've understood how it works. I just couldn't get what
              the "0x" meant but that's just a "tag" that describes the number as
              an hexadecimal, right? Well, but if the Pong is now correct then why
              does the server disconnects me? Maybe it's because of that "putting
              msgs" 2gether, how can this be overrun? what i mean is: if that
              happens then it will be very difficult to find out if a msg is
              incomplete or it it's just a wrong one or a lost or corrupted msg.
              what's wrong, do you think i should change to socket wrench's
              control? or to API calls? I've already checked that ref. and that's
              how i developed my app anyway. There's isn't much info about this
              protocol specifications though. But thanx to this yahoo group stuff
              and to your helpfull replies now all of this can be overcome and
              developing a gnutella servent will be less frustrating.
              > I think you are reading the bytes the wrong way. I think the 24
              >comes from that the default gnutella port is 6346, in hex 0x18CA.
              >0x18 is 24 in decimal. http://www.clip2.com/GnutellaProtocol04.pdf
              >is a good reference if haven't read it already.

              Thanx again Tor for you major help!
            • Jay Cornwall
              ... Perhaps if I explain briefly how my client handles reading data, it might help. To keep things simple, I always try to read one Gnutella message (header
              Message 6 of 15 , Aug 5, 2001
                On 05-Aug-01, cogumbreiro@... wrote:

                > [..] Maybe it's because of that "putting
                > msgs" 2gether, how can this be overrun? what i mean is: if that
                > happens then it will be very difficult to find out if a msg is
                > incomplete or it it's just a wrong one or a lost or corrupted msg.

                Perhaps if I explain briefly how my client handles reading data, it might
                help.

                To keep things simple, I always try to read one Gnutella message (header and
                any payload) at a time, and interpret them one at a time. I divide the read
                into two distinct parts, one for the header (of a fixed size, so that should
                be easy) and one for the payload (of a variable length, but the length is
                contained in the header).

                I have a temporary buffer (called RecvBuffer) for each connection I
                make/accept. I also keep track of the sizes (called RecvSize).

                When data has arrived for reading, I look at my RecvBuffer and see how big it
                is. If it's empty, I try and read 23 bytes (the size of the header). If it's
                not empty, but still less than 23 bytes, I try and read the remainder of the
                header. If it's more than 23 bytes, I ignore this section (the header read
                sextion).

                After reading, if I'm still unable to read up to 23 bytes, I store what I
                have in the same RecvBuffer, and update its RecvSize. I then leave, and come
                back later.

                If I manage to read the full 23 bytes, or I already had the 23 bytes, I
                enter the payload read section. I know how much data I should read (because
                its size is stored in the header, which I already have).

                If I have none of the payload yet (i.e. RecvSize = 23, only the header), I
                try and read the full payload. If I have some of the payload (i.e. RecvSize
                > 23, but less than the full size), I try and read the remainder of the
                payload.

                After reading, if I'm still unable to read the whole of the payload, I store
                what I have in the same RecvBuffer, and update its RecvSize. I then leave,
                and come back later.

                After all that, when I've got the whole header and payload, I then do what I
                want with the message. Afterwards, I clear the buffer and its size, and then
                start all over again.

                Well, I guess that's quite a lot to take in. Implementing it actually takes
                quite a lot of thought, but it's flawless when it's working. It
                automatically handles messages joined together, split messages, etc.

                Hope that helps somehow. :)

                Regards

                Jay
              • cogumbreiro@hotmail.com
                ... (header and ... the read ... that should ... length is ... But to do this procedure you ll have to consider all of the incoming data is not lost, corrupted
                Message 7 of 15 , Aug 5, 2001
                  Jay:

                  > To keep things simple, I always try to read one Gnutella message
                  (header and
                  > any payload) at a time, and interpret them one at a time. I divide
                  the read
                  > into two distinct parts, one for the header (of a fixed size, so
                  that should
                  > be easy) and one for the payload (of a variable length, but the
                  length is
                  > contained in the header).
                  >[...]
                  But to do this procedure you'll have to consider all of the incoming
                  data is not lost, corrupted or in a wrong order, does this never
                  happen for you to do that?

                  By the way if i have a blocking (synchronous) connections would that
                  help maintain data togheter (no splited data)?

                  Thx for the tip jay
                • Tor Klingberg
                  ... No, TCP takes care of that for you. ... I don t think so. You will have to use a system like Jay Cornwall s. ... Tor Klingberg tor.klingberg@gmx.net
                  Message 8 of 15 , Aug 5, 2001
                    cogumbreiro@...:
                    > But to do this procedure you'll have to consider all of the incoming
                    > data is not lost, corrupted or in a wrong order, does this never
                    > happen for you to do that?

                    No, TCP takes care of that for you.

                    > By the way if i have a blocking (synchronous) connections would that
                    > help maintain data togheter (no splited data)?

                    I don't think so. You will have to use a system like Jay Cornwall's.


                    --------------------------------------
                    Tor Klingberg
                    tor.klingberg@...
                  • Mike Green
                    Jay, ... ^^^ I know, it s weekend :-) -- Mike
                    Message 9 of 15 , Aug 5, 2001
                      Jay,

                      > sextion).
                      ^^^ I know, it's weekend :-)

                      -- Mike
                    • Andy Hedges
                      ... It is hexidecimal (ie base 16). The following, Java, code snippet should give it away... public static final int PING_DESCRIPTOR = 0x00; // 0 public
                      Message 10 of 15 , Aug 6, 2001
                        >Could you explain me what's that "0x01" i had alot of problems
                        >discovering wich value each of them would correspond to.

                        It is hexidecimal (ie base 16). The following, Java, code snippet should
                        give it away...

                        public static final int PING_DESCRIPTOR = 0x00; //
                        0
                        public static final int PONG_DESCRIPTOR = 0x01; //
                        1
                        public static final int PUSH_DESCRIPTOR = 0x40; //
                        64
                        public static final int QUERY_DESCRIPTOR = 0x80;
                        //128
                        public static final int QUERY_HIT_DESCRIPTOR = 0x81; //129
                      • Jay Cornwall
                        ... Ooops, LOL. :) Ahem. I don t think we ll go into that. ;) Regards Jay
                        Message 11 of 15 , Aug 6, 2001
                          On 06-Aug-01, Mike Green wrote:

                          >> sextion).

                          > ^^^ I know, it's weekend :-)

                          Ooops, LOL. :)

                          Ahem. I don't think we'll go into that. ;)

                          Regards

                          Jay
                        Your message has been successfully submitted and would be delivered to recipients shortly.