• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OS X Socket Performance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OS X Socket Performance


  • Subject: Re: OS X Socket Performance
  • From: Becky Willrich <email@hidden>
  • Date: Mon, 9 Sep 2002 10:07:58 -0700

My question is this: which of these options offers the highest performance? My guess is that working in straight C with BSD sockets would be, but I have a strong desire to stick with Apple's APIs in order to leverage any future enhancements to CFNetwork.

Raw sockets will give you the best performance, since all the other solutions are ultimately implemented on top of sockets. However, that's almost certainly in the noise. CFStream/CFNetwork, for instance, is a pretty thin shim over raw sockets, and our testing shows you can't notice the difference in performance unless you're communicating with the loopback address; if the packet even has to travel from the kernel to the ethernet card on the same machine, you can't see the performance hit any more. I'd expect this to be the same for other thin layers over sockets. I'm talking about bandwidth here - not latency or memory. The memory overhead of CFNetwork is around 100 bytes per open socket. Latency is trickier to quantify; if you use CFStream in a blocking fashion (let your thread block in CFReadStreamRead()), then the latency compared to raw sockets is negligible. If you attach the stream to the run loop, the latency goes up - it's imposed by the run loop. If you're only monitoring a couple sockets at a time, and you never stall the run loop, I think the latency will still be negligible. If you're scheduling dozens of sockets, you may see a latency hit. The win, though, is being able to multiplex several inputs (user events, other sockets) without having to go multi-threaded, and the bandwidth is still good until you reach the point where the run loop is never idle (i.e. you spend all your time servicing sockets or other events, and none waiting for data to arrive).

BTW, one advantage CFNetwork has over the others you mention is that it has an HTTP implementation available. In fact, even if you use a raw sockets solution, you should look at CFHTTPMessage to do the HTTP parsing for you. Another advantage is built-in SSL if you ever want to encrypt your transmissions (you'll need a cert on the server side).

REW
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: OS X Socket Performance
      • From: "Chris K." <email@hidden>
References: 
 >OS X Socket Performance (From: "Chris K." <email@hidden>)

  • Prev by Date: Re: CFSocket Callback
  • Next by Date: Re: CFSocket Callback
  • Previous by thread: Re: OS X Socket Performance
  • Next by thread: Re: OS X Socket Performance
  • Index(es):
    • Date
    • Thread