Re: CFSocket freezes
Re: CFSocket freezes
- Subject: Re: CFSocket freezes
- From: Greg Herlihy <email@hidden>
- Date: Sun, 27 Nov 2005 02:58:18 -0800
- Thread-topic: CFSocket freezes
xinetd (and launchd - since it is xinetd-compatible) offer a wide variety of
configuration options governing nearly every aspect of the server's
operation. For details, I would consult the xinetd man page (for the general
description), and the xinetd.conf man page (for the list of available
settings). Launchd supports nearly all of the same settings, except that it
cannot be configured to accept an incoming connection based on the
connection's originating ip address.
First, it is useful to note how incoming requests for a stream-oriented
service are usually handled. For a "no wait" service, xinetd launches a new
service process for each incoming request. So there is no point in writing a
multithreaded program - because each process has one - and only one -
connection to itself. Having only one thread reduces both the program's
complexity, and the time needed for debugging it - often substantially. And
having multiple processes instead of a single, multithreaded app, is a more
robust design as well, since a failure in one process has no effect on any
other.
By default there is no limit on the number of incoming connections that
xinetd will accept for a particular service. A service can specify a limit
not only for the number of simultaneous connections (either from all
addresses or per address) but can also set limits on its use of CPU cycles,
allocated memory, stack size, or any other type of system resource it may
require.
So to answer your question: I would first decide whether to set an upper
limit on the number of simultaneous connections (and perhaps connection
attempts per second). If a limit is specified, then no additional
connections would be accepted above that limit until one disconnects.
The next decision would be how to handle the set of existing connections.
The easiest solution is just to handle them all at once. If it is necessary
to "queue" existing connections until other connections have completed, then
it would be necessary for each instance of the app to coordinate the order
the connections are processed with the other instances. There are several
ways to do so, and they tend to vary greatly in elegance and complexity. One
of the more basic approaches is for each process to write a .pid file to
/var/run and then monitor changes to that directory so it knows when it
should process its queued task. But I am certain that there are more modern
ways of handling this problem.
Greg
On 11/26/05 4:03 PM, "Frank Illenberger" <email@hidden> wrote:
> The launchd approach sounds interesting. I am developing a
> multithreaded application server. I have not worked much with launchd
> services, only wrote a very small one. I am wondering: For a launchd
> service, would it be possible to schedule its work onto several run
> loops/worker threads and to queue requests if all worker threads are
> busy?
>
> Frank
>
> Am 27.11.2005 um 00:50 schrieb Greg Herlihy:
>
>> I don't have specific suggestion with regards to this particular
>> problem,
>> other than to suggest that CFSocket as high-level, client-oriented
>> API might
>> not be the optimal API to use for a network server.
>>
>> And in fact there is no need to write a network server at all on
>> the Mac. It
>> is far easier for a program to offload the server portion of its
>> execution
>> to either xinetd (pre-Tiger) or launchd (Tiger). With either of
>> those two
>> system apps handling all the issues surrounding multiple connections,
>> diconnections, timeouts, SYN floods and other headaches, the
>> program itself
>> simply has to be able to read and write standard I/O (printf
>> statements and
>> the like) to get its job done.
>>
>> And not only is an xinetd or launchd service far easier to write
>> and to test
>> than a full blown server, but it also scales better, provides better
>> security, and makes more efficient use of the computer's resources.
>> In fact
>> it is hard to think of any disadvantages with this approach.
>>
>> Greg
>>
>>
>> On 11/25/05 1:22 PM, "Frank Illenberger" <email@hidden> wrote:
>>
>>> Hi,
>>>
>>> I am developing a server using AsyncSocket/CFSocket wich is working
>>> fine with only exception, that it freezes in the acceptor thread in a
>>> call to CFWriteStreamOpen after having replied about 300-5000
>>> requests. Sometimes it answers 100.000 requests without a problem but
>>> 50% of the time it freezes after 500 requests.
>>> The stack trace of the frozen acceptor thread looks like this:
>>>
>>>
>>> #0 0xffff85d8 in ___spin_lock_relinquish () at /System/Library/
>>> Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186
>>> #1 0x90f1240c in _SocketStreamOpen ()
>>> #2 0x9076c39c in _CFStreamOpen ()
>>> #3 0x9076c314 in CFWriteStreamOpen ()
>>> #4 0x10033f48 in -[AsyncSocket openStreamsAndReturnError:]
>>> (self=0x6ad8c30, _cmd=0x1005b800, errPtr=0x0)
>>> #5 0x100338dc in -[AsyncSocket doAcceptWithSocket:] (self=0x398a40,
>>> _cmd=0x1005b8a0, newNative=21)
>>> #6 0x100387e4 in -[AsyncSocket
>>> doCFSocketCallback:forSocket:withAddress:withData:] (self=0x398a40,
>>> _cmd=0x1005b4ac, type=kCFSocketAcceptCallBack, sock=0x399030,
>>> address=0x6ad9730, pData=0xf0080664)
>>> #7 0x10038b68 in MyCFSocketCallback (sref=0x399030,
>>> type=kCFSocketAcceptCallBack, address=0x6ad9730, pData=0xf0080664,
>>> pInfo=0x398a40)
>>> #8 0x90770944 in __CFSocketDoCallback ()
>>> #9 0x90770668 in __CFSocketPerformV0 ()
>>> #10 0x9075da5c in __CFRunLoopDoSources0 ()
>>> #11 0x9075cf8c in __CFRunLoopRun ()
>>> #12 0x9075ca0c in CFRunLoopRunSpecific ()
>>> #13 0x928ea664 in -[NSRunLoop runMode:beforeDate:] ()
>>> #14 0x9292f298 in -[NSRunLoop runUntilDate:] ()
>>> #15 0x100394cc in -[WBLDefaultAdaptor runAcceptorThread]
>>> (self=0x38b280, _cmd=0x1005c354)
>>> #16 0x928db6d4 in forkThreadForFunction ()
>>> #17 0x9002b200 in _pthread_body ()
>>>
>>>
>>> Has anybody observed a similar behavior with CFSocket does anybody
>>> know a way to get around this?
>>> I am running 10.4.3.
>>>
>>> Cheers
>>>
>>> Frank
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Cocoa-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden