| Justin - thanks for taking the time to respond. I'm pretty sure you're missing the point, but it could always be me instead :)
The point here was to set up a two way communication locally on the client machine, within the application's address space. The goal is to produce a single "read stream" from which CFNetwork can pull bytes dynamically from the application code's corresponding write stream. To achieve that goal, I used the socketpair concept in conjunction with socket streams to provide CFNetwork with a read stream whose content was provided by my application code's write stream callbacks.
In this way I can provide data to CFNetwork from memory instead of, for example, from a single file on disk. In particular, this was important to me because I needed to send multiple files in a single HTTP multi-part POST. Without this solution, I would have to either read all the file data into a single HTTP request, or else copy all the files into a separate multi-part file on disk which I could then point CFNetwork at with a file read stream.
I suspect that the part of my description that set of your bogus-meter was my use of the terms "server" and "client" to refer to CFNetwork and the application code. The sockets I describe in my message quoted below are local UNIX domain sockets, and have nothing to do with the remote server, except that they're used as a tricky means of getting CFNetwork to dynamically provide data to the remote server (through its own *single*, completely separate from my sockets read/write socket).
Don't know if this helped clarify things or not :) But if it did and you still see a problem with my reasoning, please let me know!
Daniel
On Apr 27, 2006, at 2:39 PM, Justin C. Walker wrote: On Apr 27, 2006, at 05:45 , Daniel Jalkut wrote:
Hi Tommy - sorry for the delay in replying - I was out of town for a few days.
I think you're getting confused by the use of the word "pair" in different contexts. I'm also confused by this, so hopefully somebody will correct us if what I'm about to tell you is wrong.
When you create a single socket, you're creating just one half of a communication pair (say, the client half). From that single socket, you can create a "pair" of streams: one for reading and one for writing. The fact that there is a pair of streams doesn't change the fact the socket itself is unconnected to anything else.
Using socketpair, you create a pair of sockets suitable for communicating between say, a client and a server. The two sockets represent two ends of a communications channel. Picture a long pipe with your application code on one end, and CFNetwork on the other end. You've created a socket pair so you can stick one socket on your end and one on CFNetwork's end
I've lost the beginning of this thread, so I may not understand what you are doing, but the above does not seem correct to me.
A single 'socket' gets you one endpoint of a 2-way ("full duplex") stream. When it is connected, there are two endpoints communicating in both directions[*]. Exactly what flows depends on the agents at each end, of course.
The 'socketpair' call gets you a pair of sockets. Each socket acts like the above. The point of this call is to be able to have a process set up an environment for communication, via whatever mechanism underlies the socket (e.g., "local", "INET", "INET6", ...) as if the two sockets were STDIN and STDOUT, respectively[**]. It's a "socket" analog of the "pipe" system call, and intended for use in the same way as "pipe()" [in fact, it's often the actual implementation of the "pipe()" call].
The issue of client and server is totally orthogonal to sockets and how they are used. Using, e.g., TCP, two 'agents' can blast data at each other over a single connection, and the only thing that will hold the data back is the normal stuff involving available buffer space, cpu cycles, and network bandwidth. Using a pair of sockets won't have a noticeable impact (of course, that 'absolute' statement should be interpreted loosely).
If I'm missing the point, never mind :-}
Regards,
Justin
|