Professional Web Applications Themes

CFSocket string limit - Mac Programming

Hello, I have built an macosx application in C which use CFSocket. The problem i have is, when from a client application i send a string of more than 4094 characters to my application, CFSocket of my application receives this but seperates the string i sent into 2 or more pockets, and each pocket contains 4094 characters. Is this a limitation of CFSocket? if not can I change/increase this limit to 5000 characters or unlimited number of characters? or at least be able to receives the string in one pocket? Thank's alot in advance. Inoel...

  1. #1

    Default CFSocket string limit

    Hello,

    I have built an macosx application in C which use CFSocket.
    The problem i have is, when from a client application
    i send a string of more than 4094 characters to my application,
    CFSocket of my application receives this but seperates the string
    i sent into 2 or more pockets, and each pocket contains 4094
    characters.

    Is this a limitation of CFSocket? if not can I change/increase this
    limit to 5000 characters or unlimited number of characters? or at
    least be able to receives the string in one pocket?

    Thank's alot in advance.
    Inoel


    Inoel Guest

  2. #2

    Default Re: CFSocket string limit

    "Inoel Arifin" <mac> writes: 

    You cant ever rely on the sting arriving as one packet because the network
    is free to break it up into lots of little packets. Its nothing to
    do with CFSocket. When working with networking code you always need to
    program taking this into account. The converse is true too - if you write
    a [pair of 500 byte blocks thenyou can quite happily get them as a single
    1000 byte block at the far end (or four 250 byte blocks, or one 700 byte and
    one 300 byte).

    Its something most people forget aboout, and then it acuses problems when they
    try and run the app over a congested internet.

    -bat.
    Pete Guest

  3. #3

    Default Re: CFSocket string limit

    Pete French wrote: 

    at best, that's misleading, or at worst, downright wrong.

    if you use tcp/ip stream connections, all data is guaranteed to arrive,
    in the order you sent it. worst case, your connection might break if
    one end or the other goes down or if internet problems are encountered,
    but you get specific notification in that case.

    tcp/ip datagrams, on the other hand, are not guaranteed to arrive, and
    can arrive out-of-order. there is a limit to how big datagrams can be,
    but they will never be broken up into arbitrary sizes and delivered
    piecemeal. either you'll get the whole datagram or it will be lost.

    as for the original poster's question, i don't think you've given enough
    information for anybody to know what you're doing wrong. it's certainly
    possible to send any amount of data from one program to another, and to
    do so reliably.
    Jhnny Guest

  4. #4

    Default Re: CFSocket string limit

    > You cant ever rely on the sting arriving as one packet because the network 
    and 

    Please correct me if i'm wrong, is that kind of handling already be done
    by CFSocket? CFSocket has put the data in the right order and the right way.
    The only matter to me now is that how to get the rest of the data if this
    problem occure? Is there any flag or some CFx function which can tell me
    "wait there are still blocks of data available!", so i can todo something
    about it?

    thank's alot in advance.
    inoel

    "Pete French" <twisted.org.uk> wrote in message
    news:twisted.org.uk... 
    >
    > You cant ever rely on the sting arriving as one packet because the network
    > is free to break it up into lots of little packets. Its nothing to
    > do with CFSocket. When working with networking code you always need to
    > program taking this into account. The converse is true too - if you write
    > a [pair of 500 byte blocks thenyou can quite happily get them as a single
    > 1000 byte block at the far end (or four 250 byte blocks, or one 700 byte[/ref]
    and 
    they 


    Inoel Guest

  5. #5

    Default Re: CFSocket string limit

    > Pete French wrote: 

    no its correct, you just ministrepretted what I wrote.
     

    yes it is. I never said otherwise. what *isnt* guaranteed is that it will
    arrive in the same size chunks that you sent it into the network in.

    TCP only guarantees a stream of bytes in the correct order. Nothing more.
     

    No such thing as a "tcp/ip" datagram. I suspect you mean udp/ip

    -bat.
    Pete Guest

  6. #6

    Default Re: CFSocket string limit

    "Inoel Arifin" <mac> writes: 

    The network did that for you. CFSocket is (as far as I can tell) simply
    a wrapper round the normal network socket code.
     

    This is an impossible problem unless you know in advance how many bytes
    of data are written - in which case your code can tell if it has got
    the right amount of data and can then wait for more. I would
    suggest that you either add some kind of message terminating character
    so you can tell when you have all the bytes, or add a header with the length
    of the message in it so you know how many bytes you are waiting for.

    -bat.
    Pete Guest

  7. #7

    Default Re: CFSocket string limit

    hi,

    here's a piece of my code which does that all...

    thank's,
    inoel
    ----------------

    static void socket_data_callback(CFSocketRef s, CFSocketCallBackType
    callbackType, CFDataRef address, const void *data, void *info)
    {
    input_datalen = CFDataGetLength(data);
    if (input_datalen) {
    range = CFRangeMake(0, input_datalen);

    /* incoming data comes to here...
    i'd do something with it
    when the length of the incoming data is larger than 4094
    then this callback will be readed x time until the data
    is readed completely.

    my goal is to have the data at once, is this possible?
    */
    }
    }

    static void socket_serving_callback(CFSocketRef s, CFSocketCallBackType
    callbackType, CFDataRef address, const void *data, void *info)
    {
    /* ready to serve you */

    tcp_native_socket = *(CFSocketNativeHandle*)data;
    if (tcp_native_socket > 0) {
    /* prepares server socket for for data sending/receiving */
    tcpip_stream = CFSocketCreateWithNative(NULL, tcp_native_socket,
    kCFSocketDataCallBack, &socket_data_callback, NULL);
    if (tcpip_stream) {
    /* socket accepted */
    stream_runloop = CFSocketCreateRunLoopSource(NULL, tcpip_stream, 0);
    stream_runloop_ref = CFRunLoopGetCurrent();
    CFRunLoopAddSource(stream_runloop_ref, stream_runloop,
    kCFRunLoopDefaultMode);
    CFRelease(stream_runloop);
    CFRelease(tcpip_stream);
    }
    }
    }

    /*
    socket_setup

    this function sets up tcp ip socket
    */
    void socket_setup(void)
    {
    tcpip_socket = CFSocketCreate(NULL, 0, SOCK_STREAM, IPPROTO_TCP,
    kCFSocketAcceptCallBack, &socket_serving_callback, NULL);
    if (tcpip_socket) {
    tcpip_sa.sin_family = AF_INET;
    tcpip_sa.sin_addr.s_addr = INADDR_ANY;
    tcpip_sa.sin_port = htons(Settings.tcpip_portno);
    memset (&(tcpip_sa.sin_zero), '\0', 8);
    tcpip_sa.sin_len = sizeof(struct sockaddr_in);
    length = sizeof(struct sockaddr_in);

    tcp_address = CFDataCreate(NULL, (const uint8*)&tcpip_sa, length);
    socket_error = CFSocketSetAddress(tcpip_socket, tcp_address);
    if (!socket_error) {
    socket_runloop = CFSocketCreateRunLoopSource(NULL, tcpip_socket, 0);
    CFRunLoopAddSource(CFRunLoopGetCurrent(), socket_runloop,
    kCFRunLoopDefaultMode);
    CFRelease(socket_runloop);
    } else {
    /* dispose */
    }
    }
    }


    "Jhnny Fvrt (it means "genetic antagonism")" <com> wrote
    in message news:nashville.comcast.net... 
    >
    > at best, that's misleading, or at worst, downright wrong.
    >
    > if you use tcp/ip stream connections, all data is guaranteed to arrive,
    > in the order you sent it. worst case, your connection might break if
    > one end or the other goes down or if internet problems are encountered,
    > but you get specific notification in that case.
    >
    > tcp/ip datagrams, on the other hand, are not guaranteed to arrive, and
    > can arrive out-of-order. there is a limit to how big datagrams can be,
    > but they will never be broken up into arbitrary sizes and delivered
    > piecemeal. either you'll get the whole datagram or it will be lost.
    >
    > as for the original poster's question, i don't think you've given enough
    > information for anybody to know what you're doing wrong. it's certainly
    > possible to send any amount of data from one program to another, and to
    > do so reliably.[/ref]


    Inoel Guest

  8. #8

    Default Re: CFSocket string limit

    In article <nashville.comcast.net>,
    Jhnny Fvrt (it means "genetic antagonism") <com>
    wrote:
     
    >
    > at best, that's misleading, or at worst, downright wrong.
    >
    > if you use tcp/ip stream connections, all data is guaranteed to arrive,
    > in the order you sent it. worst case, your connection might break if
    > one end or the other goes down or if internet problems are encountered,
    > but you get specific notification in that case.[/ref]

    They all arrive, but they don't necessarily arrive in the same chunks
    they were started with. What Pete wrote is exactly correct. Streams make
    no distinction about packet boundaries. So if you use a single read
    operation, you have no idea how much you will read, and in particular it
    has nothing to do with how much you wrote with one operation. When
    writing code on a local machine, it's common to assume that. So you
    write a 2k chunk of data, then read it and everything works. Then when
    you get out on the internet, the data gets delivered in 1k chunks, and
    the code fails. This doesn't imply that TCP lost the data, it just means
    that TCP is free to deliver the later parts of the data whenever it
    wants. If you need to read a certain amount of data, you are required to
    keep reading from the socket until it all arrives. If you need
    boundaries in your data, you must provide them yourself.
     

    Teeny tiny nit; datagrams can get split up, but they're always
    reassembled before they're handed to user processes. But I'm sure you
    knew that.
     

    It certainly is, *if* you avoid making incorrect assumptions.
    Assumptions like, 'if I send an X byte chunk, then I can read an X byte
    chunk' are incorrect, and that is what the original poster was doing.
    Michael Guest

  9. #9

    Default Re: CFSocket string limit

    In article <btjqoj$k50$cistron.nl>,
    "Inoel Arifin" <mac> wrote:
     

    No, unless CFStreams provides this ability on top of TCP. What you have
    to do is store the data as it comes in in some central place. For
    example, you could have a CFData object that you can get to in your
    callback (use that *info parameter to get to it) and add the new data
    onto it. When you gather enough, then you can pass the entire chunk off
    to whatever should process it. Your callback will not recieve data in
    any predictable sizes.
    Michael Guest

  10. #10

    Default Re: CFSocket string limit

    I'll take a look in to that.
    Thank you all for your help.

    gr,
    inoel



    "Pete French" <twisted.org.uk> wrote in message
    news:twisted.org.uk... [/ref]
    way. [/ref]
    me [/ref]
    something 
    length 


    Inoel Guest

Similar Threads

  1. Limit on maximum String length?
    By Heman Robinson in forum Macromedia Flex General Discussion
    Replies: 1
    Last Post: April 19th, 05:34 PM
  2. getURL string size limit?
    By weezil webforumsuser@macromedia.com in forum Macromedia Flash Actionscript
    Replies: 4
    Last Post: February 6th, 05:51 AM
  3. Replies: 4
    Last Post: December 12th, 06:55 PM
  4. ASP String limit
    By Jay in forum ASP
    Replies: 6
    Last Post: September 11th, 09:17 PM
  5. Replies: 1
    Last Post: July 3rd, 05:45 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139