More progress (and sample project updated -
http://ericgorr.net/pq/AF_UNIX_GCD_Client.zip)...
It looks like the server is working (although, it still may be a bit
fragile).
The current problem is getting the client to read the reply coming back
from the server.
I have a handler on DISPATCH_SOURCE_TYPE_READ and the handler block is
getting called. However, the 'accept' call is setting errno to
22...invalid parameter. I am not certain what that invalid parameter
might be yet since it is essentially the same code from the server. But,
that may be the issue...there may be a subtle difference between how the
client code needs to be written vs the server code which I don't yet
understand.
In any case, I do seem to be very close to getting a round trip data
transfer between client and server...just need the client to read the
reply.
On Tue, 26 Jul 2011 07:04:45 -0500, email@hidden wrote:
Well, I solved one of the problems in my sample project.
In client_write_request, I had:
__block size_t track_sz = length;
when it should have been:
__block size_t track_sz = sizeof(struct ss_msg_s) + length;
So, I was not sending as much data as the server was expecting and,
after canceling the write, the server may not have been responding to
the cancellation correctly...still need to investigate that one.
However, the server is still not behaving correctly. It seems to be
expecting even more data and gets stuck calling server_accept many,
many times.
In any case, I have updated the sample project with this fix.
On Mon, 25 Jul 2011 22:25:58 -0500, email@hidden wrote:
So, I've got another sample project at:
http://ericgorr.net/pq/AF_UNIX_GCD_Client.zip
In the readme for the SSD sample code, it mentions that the client
should be sending and receiving data to and from the server
asynchronously using GCD. So, that is what I am attempting next, but
using AF_UNIX sockets. However, it isn't working.
In the sample project, the only thing that is going on currently is
that I connect to the server and then close the connection by
closing
the file descriptor. The behavior that I am seeing on the server end
is that it believes it has data and just constantly tries to read
data
that isn't there. So, clearly, I am not disconnecting from the
server
correctly or, perhaps, it is against the rules to connect without
doing anything further.
In the main function, there are also three lines of code commented
out:
//assert( client_read_replies( sfd ) );
//assert( client_send_request( sfd, req ) );
//dispatch_main();
They were attempts to see if I could get the reading and writing of
data from and to the server working.
If they are uncommented...
client_read_replies attempts to set up a DISPATCH_SOURCE_TYPE_READ
handler to receive data back from the server. However, even with
this
handler installed, it is never called.
client_send_request sets up a DISPATCH_SOURCE_TYPE_WRITE handler.
This appears to work correctly...to a point. As near as I can tell,
the data does get written and I can see the server start to respond,
but then both the client and the server lock up. The server never
seems to fully read the data sent and never tries to send a reply
back. I have tried setting the file descriptor to non-blocking, but
that doesn't appear to help.
dispatch_main simply enters into an event loop. I don't imagine
there
is anything wrong with doing this.
I can only imagine the number of things I am doing wrong on the
client side. As always, any advice or suggestions are appreciated.