Re: Trouble getting SSD Project working & Questions
Re: Trouble getting SSD Project working & Questions
- Subject: Re: Trouble getting SSD Project working & Questions
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Mon, 18 Jul 2011 12:09:19 +0100
On 16 Jul 2011, at 18:06, email@hidden wrote:
> 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?
Yes. I took your code, built it, and installed it, and this worked as expected.
$ sudo mkdir -p /usr/local/libexec
$ sudo cp build/Debug/ssd /usr/local/libexec/
$ sudo cp com.apple.ssd.plist /Library/LaunchDaemons/
$ sudo launchctl load /Library/LaunchDaemons/com.apple.ssd.plist
$ sudo launchctl list com.apple.ssd
{
"Label" = "com.apple.ssd";
"LimitLoadToSessionType" = "System";
"OnDemand" = true;
"LastExitStatus" = 0;
"TimeOut" = 30;
"Program" = "/usr/local/libexec/ssd";
"ProgramArguments" = (
"ssd";
"launchd";
);
"EnableTransactions" = true;
"TransactionCount" = -1;
"Sockets" = {
"com.apple.ssd.sock" = (
file-descriptor-object;
file-descriptor-object;
);
};
};
> [...] the real question is how can I independently determine the server is ready and able to go?
That depends on the context. For debugging, "launchctl list" and actually checking the service port via telnet are both good. For production, you should just try to connect to the service port, and not try to use launchctl to second guess launchd.
> 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.
>
> [...]
>
> Any idea on why the server may not be running?
Well, it sounds like you're having installation problems, so that's the first thing I'd look at. After that, look at my comments below.
> 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.)
There really is no good Mac GUI alternative to Wireshark, which is a shame because I just can't cope with Wireshark's UI. There are, however, a number of options available, each of which is good in its own particular context. See QA1176 "Getting a Packet Trace" for the list of tools that I know about.
<http://developer.apple.com/library/mac/#qa/qa2001/qa1176.html>
> 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;
> }
Yeah, I agree that there's something wonky there. After fixing this problem (I just moved the line that adds nbytes to *total to immediately after the read() and adjusted the following code accordingly) I got the client/server round trip working. Yay!
> 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?
The sample is intended to be a network server sample, hence the use of TCP. If you want to create a non-network service, you should definitely use AF_UNIX. It definitely performs better but, more importantly, it guarantees that you'll only be accessed by local processes.
> 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?
Not quite. Your first point is correct--incoming data can be spread over multiple events--but there's some subtlety to the second point. read() does not guarantee to return all of the data you asked for, it just guarantees to return some data. However, if read() does not return all the data, the descriptor will still be readable and the source will queue another block to read the remaining data.
> 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.
The problem with doing this is that you tie up a thread for the duration of the read. If the message is large, or coming in slowly, that's using a thread for no good reason. The approach shown by the sample is generally the one we recommend.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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