Trouble getting SSD Project working & Questions
Trouble getting SSD Project working & Questions
- Subject: Trouble getting SSD Project working & Questions
- From: email@hidden
- Date: Sat, 16 Jul 2011 12:06:08 -0500
I am trying to figure out the SSD sample code project from WWDC 2010.
I've got a slightly modified version at http://ericgorr.net/pq/ssd.zip
If there is a better mailing list to post this to, please let me know.
The modifications consist of the following:
1. some fprintf statements so I can better follow what the code is
doing as it is running
2. an additional run script build phase for the SSD target to move
things into place. You may want to take a look at the script so you know
what it is doing. The ReadMe for the project explains why.
My questions are:
1.
After doing sudo launchctl load
/Library/LaunchDaemons/com.apple.ssd.plist, should I then be able to do
launchctl list and see the ssd socket server show up?
I do not. However, when running the client, it can connect and it
appears to be sending the message to the server. So, I suppose the real
question is how can I independently determine the server is ready and
able to go?
2.
The client enters the code where it is waiting for the reply and then
just hangs there. I have some printf statements in the server code, but
they do not appear in any log files, so I am not sure if it is actually
running or not.
I can even use Wireshark and watch the message being sent. (p.s. Is
there any good Mac GUI app that would allow me to watch the
communication? Wireshark is powerful, but probably overkill in this
situation and an more Mac friendly app may actually be more useful.)
Any idea on why the server may not be running?
3.
I was looking at the server_read code in ssd.c. Something doesn't seem
quite right about it and I am wondering if I a missing something. Say,
for example,
nbytes = read(fd, track_buff, track_sz);
reads everything in one pass. The total variable will still be assigned
a value of 0 and:
if (msg->_len == (*total - sizeof(struct ss_msg_s)))
{
result = true;
}
will never resolve to true and result will still be false. Now, after
this check, the total variable is updated with the number of bytes read,
but by then it is to late. There is no more data to read.
So, what I am wondering is if the check should really be:
if (msg->_len == (nbytes + *total - sizeof(struct ss_msg_s)))
{
result = true;
}
4.
The ReadMe says:
"the service advertised on the TCP port 1138"
which is confirmed by the usage of AF_INET in the source. I am just
wondering why one might choose this address family over AF_UNIX. Are
there any differences in performance characteristics? Is one generally
more reliable?
5.
I also had a few questions about the general design of the server and
how it is reading data. It sets up an event handler using:
dispatch_source_t as =
dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, fd, 0, mq);
Now, if my understanding is correct, this is leveraging Grand Central
Dispatch (GCD), allowing it to recognize when new data is available to
be read. When it sees to data, it generates an event and server_read is
called to read the available data.
The design of server_read would indicate that it is possible for the
amount of data being sent to be spread over multiple events. The
implementation would also imply that the amount of data to be read per
event can all be read with the call read(fd, track_buff, track_sz). Is
this correct?
I have seen other similar code that when a server sees there is data to
read, it enters into a tight while loop and continues to read data until
it gets it all.
I am just curious how one might best argue for one design over another
in a case like this sample code. Does the event method play better with
Instant Off, etc.? Why would one choose the event method in this case?
Those are all of my questions for now.
Thank you for reading this far. :-)
_______________________________________________
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