Announcement

Collapse
No announcement yet.

TCP RECV buffer length

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • TCP RECV buffer length

    Hi everybody,

    what is the maximum buffer length in the TCP RECV statement. Is
    this 1024 bytes or can it be anything higher (32 KB ?), although
    I tried that but it didn't work. Can you augment the buffersize ?

    Steve.

    ------------------
    So here we are, this is the end.
    But all that dies, is born again.
    - From The Ashes (In This Moment)

  • #2
    I'm not aware that there is an arbitary limit imposed by PowerBASIC, however, it is usually better to read in smaller chunks and assemble it all together while checking for errors. Something like this:
    Code:
    CASE %FD_READ
      Buffer$ = ""
      Chunk$ = ""
      ERRCLEAR
      DO
        TCP RECV #hTcp, 1024, Chunk$
        Buffer$ = Buffer$ + Chunk$
      LOOP WHILE ISTRUE LEN(Buffer$) AND ISFALSE EOF(hTcp) AND ISFALSE ERR
    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    Lance
    mailto:[email protected]

    Comment


    • #3
      ISTRUE LEN(Buffer$) AND ISFALSE EOF(hTcp) AND ISFALSE ERR

      Lance, shouldn't the statement shown above be

      (ISTRUE LEN(Buffer$)) AND (ISFALSE EOF(hTcp)) AND ISFALSE ERR

      ------------------
      Dominic Mitchell
      Dominic Mitchell
      Phoenix Visual Designer
      http://www.phnxthunder.com

      Comment


      • #4
        Why? It is using Short-Circuit evaluation and how it works is instantly clear without adding parentheses.

        Actually there was an error in that statement... it should have read:
        Code:
        LOOP WHILE ISTRUE LEN(Chunk$) AND ISFALSE EOF(hTcp) AND ISFALSE ERR
        ------------------
        Lance
        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        Lance
        mailto:[email protected]

        Comment


        • #5
          steven --
          1024 is a figure from the sky.
          below is a fragment, which i wrote before poffs appearence.
          play with kbuffer.
          you can increase it, lets say to 32k, but (it seems to me) web-site sends chunks 8k maximum.
          99,99% sure that web-server defines maximum size of chunks.
          of course, own buffer should be enough large to avoid additional restrictions (i think 8-16k, but better to test certain web sites).

          [CODE]
          #compile exe
          #register none
          #dim all
          #include "win32api.inc"

          $forum = "4"
          %idx1 = 1100
          %idx2 = 1110
          function pbmain
          dim buffer as string, kbuffer as long, i as long, j as long
          dim idx as long, pgnm as string, pref as string
          for idx = %idx1 to %idx2
          pref = "
          do
          tcp open port 80 at "www.powerbasic.com" as #1 timeout 5000
          pgnm$ = format$(idx, "000000") + pref + ".html"
          cls: print pgnm$
          tcp print #1, "get <a href="http://ru

          Comment


          • #6
            Hi,

            Yes, I guess everybody's right concerning the 1024, i need to
            check for the length of the buffer. Now I seem to have another
            problem. I send a structure. The structure contains the
            member length. Length is defined as a Long. When I put the
            value 10 in there which is a Line Feed char, and send that
            the receiving part gets confused. It thinks it is a LF. How to
            solve this one ?

            I came up with a check of the length. if the length is less than
            26 (special chars) I make the value negative and then on the client
            side I use the ABS to obtain the length. It works but is this the
            way to do it or are there other alternatives?


            ------------------
            So here we are, this is the end.
            But all that dies, is born again.
            - From The Ashes (In This Moment)

            Comment


            • #7
              You are on the right track - you need to work out your own "data protocol" so that you can transfer binary data back and forward without regard to how TCP actually gets the data there.

              You may also want to add some form of checksum into the data to make sure the packets contain reliable data, and that you can pick out a "structure" from the data with reliability.

              PS: you should be using TCP RECV rather than TCP LINE if you are passing binary data.

              ------------------
              Lance
              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              Lance
              mailto:[email protected]

              Comment


              • #8
                istrue and isfalse are unary operators, and as such, potentially affect every operand
                to the right (subject to precedence rules). you appear to be expecting them to act as
                functions, affecting only the operands within parentheses. an incorrect interpretation.
                that is a quote from bob. see the following http://l]http://l

                the loud description of the debugger was bad form on my part. sorry about that.

                ps
                disregard my previous posts. my head finally cleared. i think i got up too early.

                [this message has been edited by dominic mitchell (edited june 18, 2001).]
                Dominic Mitchell
                Phoenix Visual Designer
                http://www.phnxthunder.com

                Comment


                • #9
                  My "updater", which works on hundreds PCes, downloads binary files from HTTP (using TCP RECV) without any problems.
                  Control - yes, it's necessary. I attach even two independent CRC32 to all files.

                  ------------------
                  E-MAIL: [email protected]

                  Comment


                  • #10
                    I have run into a limit of 64 k, but I can't remember if that was sending or receiving.
                    --Don

                    ------------------
                    dickinson.basicguru.com
                    Don Dickinson
                    www.greatwebdivide.com

                    Comment

                    Working...
                    X