• 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: Network Programming Models (was OTCountFreeBytes?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network Programming Models (was OTCountFreeBytes?)


  • Subject: Re: Network Programming Models (was OTCountFreeBytes?)
  • From: email@hidden
  • Date: Mon, 4 Feb 2002 15:06:07 -0500

I don't want to start a religious war on the topic of OT vs BSD sockets but...

On Monday, February 4, 2002, at 02:24 PM, Quinn wrote:

At 11:00 -0800 4/2/02, Duane Murphy wrote:
I am curious about this comment (bletch). I am new to unix network
programming and this seemed to be a fairly powerful non-blocking way of
dealing with sockets.


o You can only select on a limited number of file descriptors simultaneously. This limit, FD_SETSIZE, is currently 1024, which is way too limiting for a serious server product.

This is not correct. The real limit is the kernel's per-process limit on open files, and unless there is some real magic happening somewhere, OT apps have this limit as well.FD_SETSIZE is just a macro that can be set to whatever you want on most UNIX implementations. I haven't verified this personally for OSX, but the OSX man page for select agrees with me (see man select).

o select just returns when something happens--it doesn't tell you what happened. So you have to walk each of your fd_set's (these are
parameters to select, type "man select" in Terminal for the gory details) looking for the ones that fired. For large fd_sets this can be slow.

You can tell select what events you are looking for, and it will return when those events happen on the descriptors of interest. The "big fat loop through all descriptors" implementation is just what you see in the text books. Real applications are smarter than this.

o select results in a programming model just like OT notifiers: everything has to be a state machine. Having grown up on the Mac I don't mind this programming model--it actually feels kinda normal--but I've debugged enough developer code to convince me that not everyone else feels the same way.

Very large, very useful, and very clear implementations have been built on this model see for example the ACE framework:
http://www.cs.wustl.edu/~schmidt/ACE-papers.html

If you're new to UNIX network programming I highly recommend "UNIX Network Programming" (ISBN: 013490012X) by Stevens. This is one of the best programming books I've ever read on any topic.

Hear! Hear! Also, if you are new to UNIX programming, Stevens wrote another really good book called "Advanced Programming in the UNIX environment" that you will also find very useful.

email@hidden


  • Follow-Ups:
    • Re: Network Programming Models (was OTCountFreeBytes?)
      • From: Peter Sichel <email@hidden>
References: 
 >Re: Network Programming Models (was OTCountFreeBytes?) (From: Quinn <email@hidden>)

  • Prev by Date: Re: Network Programming Models (was OTCountFreeBytes?)
  • Next by Date: Re: Recommended API for two-way transfers
  • Previous by thread: Re: Network Programming Models (was OTCountFreeBytes?)
  • Next by thread: Re: Network Programming Models (was OTCountFreeBytes?)
  • Index(es):
    • Date
    • Thread