• 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: Using CFSocket to connect
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using CFSocket to connect


  • Subject: Re: Using CFSocket to connect
  • From: Becky Willrich <email@hidden>
  • Date: Tue, 2 Jul 2002 11:20:48 -0700

Does the fact that I need to explicitly create my own timer mean that the
timeout argument is ignored in the current implementation?

Which timeout do you mean? CFSocket does not muck with the socket it's given, so if you have set the read/write timeouts on the underlying socket, they will be respected. But keep in mind that the OS does not use the write timeout as the connect timeout, and in fact, at the socket level, there's no way to set the connect timeout. CFSocket respects the timeout specified in CFSocketConnectToAddress, interpreting 0 as "block forever, waiting for the connect" and any negative value as "start the connect and return immediately, allowing the connect to proceed in the background". Any positive value is interpreted as "block for at most that many seconds waiting for the connect". CFStreams on sockets try to respect the read and write timeouts on the socket (if they were instantiated from pre-existing sockets), but makes no guarantees (for instance, if it needs to negotiate an SSL handshake).

I haven't worked myself up to CFStreams yet. I'm still working on migrating
my threads-and-bsdsockets code into the CF world.

Fair enough. :)

How efficient are CFStreams with large streams? I have a distribution
architecture that moves about 400MB/day around multiple machines. This
seems like it could be ideal if it can handle it quickly and without undo
memory or CPU load.

They're pretty efficient - our tests show that unless you're hitting the loopback address, you won't see any loss of bandwidth compared to using raw sockets. That's comparing select-based socket I/O with event-driven CFStreams. You'll see a slight CPU overhead from needing to run the run loop, and of course a memory overhead per socket (on the order of 100 bytes, I believe). All that said, we have only done isolated, single-connection tests, and have not tested multiple connections all under heavy load.

When is this stuff going to be documented anyway? :-)

Um, RSN....? :) Seriously, it's in the works, and there is some documentation available on CFStream already. Unfortunately, that documentation assumes run loop knowledge, and there's no CFRunLoop documentation yet....

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.

References: 
 >Re: Using CFSocket to connect (From: Mike Laster <email@hidden>)

  • Prev by Date: Re: Using CFSocket to connect
  • Next by Date: Re: Using CFSocket to connect
  • Previous by thread: Re: Using CFSocket to connect
  • Next by thread: Re: Using CFSocket to connect
  • Index(es):
    • Date
    • Thread