Professional Web Applications Themes

CFSocket - Mac Programming

Hello, I have the following problem: I'm using CFSockets and the first time the program executes it works fine. The second time the program fails on the function CFSocketSetAddress(). If I use a different port number the second time then it doesn't fail. So it looks like the computer thinks the port is still in use. I'm actually creating a TCP Callback socket with CFSocketCreate. If I don't receive any data on that socket the program will run properly the 2nd time and the 3rd etc. So only when I receive some data in the TCP Callback function is the ...

  1. #1

    Default CFSocket

    Hello,

    I have the following problem: I'm using CFSockets and the first time the
    program executes it works fine. The second time the program fails on the
    function CFSocketSetAddress(). If I use a different port number the second
    time then it doesn't fail. So it looks like the computer thinks the port is
    still in use.

    I'm actually creating a TCP Callback socket with CFSocketCreate. If I don't
    receive any data on that socket the program will run properly the 2nd time
    and the 3rd etc. So only when I receive some data in the TCP Callback
    function is the port (where the TCP Callback socket listens on) still
    blocked after I shutdown and restart my program. If I wait for 15 minutes or
    so then the port isn't blocked anymore (probably because of a time out) and
    the program will run fine.

    Because the problem only occurs when I receive something on the socket I'm
    thinking perhaps there's something wrong with my code in that callback.
    Below my e-mail you will find a piece of the callback code.

    I store all the CFSocketRef values in a linked list and at the end of my
    program I walk through the linked list and call CFSocketInvalidate() and
    CFRelease().

    Any idea why the port stays blocked?

    Regards...

    void tcp_callback(CFSocketRef s, CFSocketCallBackType callbackType,
    CFDataRef address, const void *data, void *info)
    {
    #pragma unused (s)
    #pragma unused (callbackType)
    #pragma unused (info)

    CFSocketNativeHandle tcp_native_socket;
    CFRunLoopSourceRef socket_runloop;
    CFRunLoopRef runloop_ref;
    CFIndex length;
    CFSocketRef ssocket;
    CFRange range;
    struct sockaddr_in sender_address;

    length = CFDataGetLength(address);
    if (length >= sizeof(struct sockaddr_in)) {
    range = CFRangeMake(0, length);
    CFDataGetBytes(address, range, (unsigned char*)&sender_address);
    tcp_native_socket = *(CFSocketNativeHandle*)data;
    if (tcp_native_socket > 0) {
    ssocket = CFSocketCreateWithNative(NULL, tcp_native_socket,
    kCFSocketDataCallBack, &data_callback, NULL);
    if (ssocket) {
    add_linked_list(&mac_sockets, ssocket);
    socket_runloop = CFSocketCreateRunLoopSource(NULL, ssocket, 0);
    runloop_ref = CFRunLoopGetCurrent();
    CFRunLoopAddSource(runloop_ref, socket_runloop, kCFRunLoopDefaultMode);
    }
    }
    }
    }

    void data_callback(CFSocketRef s, CFSocketCallBackType callbackType,
    CFDataRef address, const void *data, void *info)
    {
    #pragma unused (s)
    #pragma unused (callbackType)
    #pragma unused (address)
    #pragma unused (info)

    CFIndex length;
    CFRange range;
    int32 code;

    length = CFDataGetLength(data);
    if (length) {
    range = CFRangeMake(0, length);
    CFDataGetBytes(data, range, (unsigned char *)&code);
    if (code == 1234) {
    // show an alert
    }
    }
    }


    Fred Guest

  2. #2

    Default Re: CFSocket

    Hi Fred,


    "Fred" <aa.invalid> writes: 

    It does this with client (active) sockets. TCP keeps the port
    reserved for a while after the code has closed it. That is so that
    stray packets that may still come in this connection will not cause
    problems with a new connection. Remember that the underlying IP
    protocol is considered unreliable, so packets may come in twice etc.

    There is some socket options to disable that behaviour, but in general
    you are advised to not use fixed local ports for client sockets.


    benny
    Benjamin Guest

  3. #3

    Default Re: CFSocket

    Hi Benjamin,

    "Benjamin Riefenstahl" <de> wrote in message
    news:benny.turtle-trading.net... 
    >
    > It does this with client (active) sockets. TCP keeps the port
    > reserved for a while after the code has closed it. That is so that
    > stray packets that may still come in this connection will not cause
    > problems with a new connection. Remember that the underlying IP
    > protocol is considered unreliable, so packets may come in twice etc.[/ref]

    Okay that seems very logical.
     

    I think you mean the option SO_REUSEADDR I tried this and it worked! Does
    this have any other side effects or can I safely use this option in my
    application?

    Thanks for you help.


    Fred Guest

  4. #4

    Default Re: CFSocket

    Hi Fred,

    "Fred" <aa.invalid> writes: 

    I don't really know.

    Just curious, why can't you work with dynamic port assignments as
    everybody else does?

    benny
    Benjamin Guest

  5. #5

    Default Re: CFSocket

    "Benjamin Riefenstahl" <de> wrote in message
    news:benny.turtle-trading.net... 

    It's some form of network copy protection so I have to use hardcoded ports
    to let the applications find each other on the network.

    Regards


    Fred Guest

  6. #6

    Default Re: CFSocket

    In article <c0csig$kch$cistron.nl>, "Fred" <aa.invalid> wrote:
     
    >
    > It's some form of network copy protection so I have to use hardcoded ports
    > to let the applications find each other on the network.[/ref]

    No, you don't. This is what Rendezvous is for.

    hth

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  7. #7

    Default Re: CFSocket

    "Miro Jurisic" <org> wrote in message
    news:mit.edu... 
    > >
    > > It's some form of network copy protection so I have to use hardcoded[/ref][/ref]
    ports 
    >
    > No, you don't. This is what Rendezvous is for.[/ref]

    I know but I'm running as a plug-in under another app and can't get to
    Rendezvous functions because the app is Carbon and as far as I known
    Rendezvous isn't carbon.

    Regards


    Fred Guest

  8. #8

    Default Re: CFSocket

    On Wed, 11 Feb 2004, Fred wrote:
     [/ref]
    > ports 
    > >
    > > No, you don't. This is what Rendezvous is for.[/ref]
    >
    > I know but I'm running as a plug-in under another app and can't get to
    > Rendezvous functions because the app is Carbon and as far as I known
    > Rendezvous isn't carbon.
    >[/ref]

    Wrong. I'm using rendezvous just fine in my carbon mach-o code. If your
    host app is cfm then it will be a little more hassle but still possible.

    Fred

    Frederick Guest

  9. #9

    Default Re: CFSocket

    In article <c0dj69$eoo$cistron.nl>, "Fred" <aa.invalid> wrote: 

    Incorrect.

    Starting from Apple's Rendezvous page:
    <http://developer.apple.com/macosx/rendezvous/index.html>

    Cocoa:
    <http://developer.apple.com/doentation/Cocoa/Reference/Foundation/ObjC
    _classic/Classes/NSNetService.html>

    Carbon:
    <http://developer.apple.com/doentation/Networking/Conceptual/CFNetwork
    /Chapter_1/chapter_1_section_2.html>

    and if that isn't enough, source code to it is even available here:
    <http://developer.apple.com/darwin/projects/rendezvous/>
    Under the Apple Public Source License.
    Tom Guest

  10. #10

    Default Re: CFSocket

    Hi Fred,
     [/ref]

    "Fred" <aa.invalid> writes: 

    You usually need hardcoded (or otherwise pre-determined) ports for
    servers, of course.

    But as I understand it, the problem is with clients, not with servers.
    So assuming that my understanding is correct and if we are still
    talking about the same thing, why do you need hardcoded ports for the
    client?

    benny
    Benjamin Guest

  11. #11

    Default Re: CFSocket

    Benjamin Riefenstahl wrote: 
    >
    > You usually need hardcoded (or otherwise pre-determined) ports for
    > servers, of course.
    >
    > But as I understand it, the problem is with clients, not with servers.
    > So assuming that my understanding is correct and if we are still
    > talking about the same thing, why do you need hardcoded ports for the
    > client?[/ref]

    if you're going to implement network copy-protection, that's a
    peer-to-peer scenario. two or more copies of the program find each
    other on the network and swap serial numbers, to see if the user is
    cheating. peer-to-peer is really client/server where every node is both
    client and server. so he's got to open up hard-coded port numbers for
    the server side, the same as a web server would.

    for the original poster: you could get around the problem AND make your
    code more robust by implementing your protocol to use a RANGE of port
    numbers, not just one. the server side should open one of, say, ten
    possible port numbers, and clients should listen on all ten ports, if
    they can open them all. that way you're protected if some other program
    already has your preferred port open, and also if the tcp/ip stack has
    that port closed off for awhile.

    or, as other posters have mentioned, you could use rendezvous and
    side-step the whole issue.
    Jhnny Guest

  12. #12

    Default Re: CFSocket

    "Jhnny Fvrt (it means "halo, then resonate")" <com> wrote
    in message news:nashville.comcast.net... 

    Yes that is correct.
     

    That's a good Idea indeed I will look into that.

    Regards.


    Fred Guest

  13. #13

    Default Re: CFSocket

    Hi Jhnny,


    Jhnny Fvrt (it means "halo, then resonate") <com> writes: 

    Yes I know all that. But to repeat, my understanding is that servers
    don't have the problem. It's the clients that have it. And clients
    can use dynamic port assignment. Even in a peer-to-peer scenario
    because that is just a concept on top of client/server as far as TCP
    is concerned. What am I missing?


    benny
    Benjamin Guest

  14. #14

    Default Re: CFSocket

    "Benjamin Riefenstahl" <de> wrote in message
    news:benny.turtle-trading.net... 

    In my case I had a problem registering the server socket because it stayed
    in use after I closed my program. The client socket uses dynamic ports. I
    don't know why other server programs doesn't have this problem, perhaps
    because they also set the SO_REUSEADDR flag for that socket?


    Fred Guest

  15. #15

    Default Re: CFSocket

    In article <c0ipak$st0$cistron.nl>, "Fred" <aa.invalid> wrote:
     
    >
    > In my case I had a problem registering the server socket because it stayed
    > in use after I closed my program. The client socket uses dynamic ports. I
    > don't know why other server programs doesn't have this problem, perhaps
    > because they also set the SO_REUSEADDR flag for that socket?[/ref]

    Possibly. Or else they just get around the problem by starting up and
    then running for a long time without shutting down.

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 2.0: Delocalize, Repair Permissions, lots more.
    See http://www.atomicbird.com/
    Tom Guest

  16. #16

    Default Re: CFSocket

    Hi Fred,

    "Fred" <aa.invalid> writes: 

    Hm. I didn't know that the problem occurs with server sockets, too.
    And I can't really see why it does that, either. The listener socket
    doesn't send network packets and it doesn't accept arbitrary packets,
    just those specific to incoming connections. And the incoming
    connections themself only come in much later anyway. Curious.

    If SO_REUSEADDR works it is probably o.k. than.

    benny
    Benjamin Guest

Similar Threads

  1. CFSocket string limit
    By Inoel in forum Mac Programming
    Replies: 9
    Last Post: January 8th, 04:24 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