Re(2): Pass socket to kernel?
Re(2): Pass socket to kernel?
- Subject: Re(2): Pass socket to kernel?
- From: "Peter Lovell" <email@hidden>
- Date: Mon, 1 Jan 2007 13:43:41 -0500
>It sounds like it might be better for me to have the user space code
>drive the interactive processes, but have the kernel create the socket
>and do all the reads/writes:
>
>App tells kernel to connect to host A.
>Kernel opens socket and connects.
>If server requires auth, tell app to ask user.
>App gets auth info from user and send it to kernel.
>Kernel uses auth info from app to negotiate with server.
>etc.
>
>I had hoped to avoid a lot of this back and forth messaging by doing
>as much as possible in user space. From what I can tell, even doing
>something like a DNS lookup requires user-space code since APIs like
>getaddrinfo don't seem to be available in the kernel. So I think I'll
>need to call getaddrinfo, send the first address to the kernel to try
>and if kernel responds that it failed, try the next one, etc.
>
>Unless there is an easier way, this doesn't seem too bad though. It's
>sorta like doing it from an app except instead of waiting for
>something like a CFSocket callback for a connect failure, it's waiting
>for callback from a kernel notification saying it failed to connect.
This is a reasonable approach, and probably about as good as can be done.
It's nice to avoid messaging but even better to avoid doing things in
the kernel which should be done in user space. DNS is a good example -
you can do it from within the kernel but it's much harder and opens up
all kinds of error scenarios. Despite the messaging, it is better to do
this in user space. You might pass the whole list to the kernel at once
rather than one at a time.
One thing to think about in your design is the question of which part
(user/kernel space) is the conceptual controller for what you're doing.
That is, which part is the client (does the driving, makes the
decisions) and which part if the server (does what it's asked, doesn't
make any major decisions). Someone has to own this high-level decision
making, and which it is will have the major impact on your overall design.
Cheers.....Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden