Re: Trouble getting SSD Project working & Questions
Re: Trouble getting SSD Project working & Questions
- Subject: Re: Trouble getting SSD Project working & Questions
- From: email@hidden
- Date: Mon, 18 Jul 2011 20:45:13 -0500
On Mon, 18 Jul 2011 12:09:19 +0100, Quinn "The Eskimo!" wrote:
On 16 Jul 2011, at 18:06, email@hidden wrote:
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.
Yes, I took another look at it based on your comments and it was an
simple installion issue that I was glazing over.
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>
Thank you. That list of application is quite useful.
Perhaps someday someone will take on the challenge of creating an
application as powerful as Wireshark with a nice GUI on top of it.
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,
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!
Ya, that makes sense.
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.
Well, eventually, the real case will be wrapped as a secure helper
tool,
so that will provide the limitation on who can call it, but knowing
that
AF_UNIX offer much better performance is quite useful.
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.
Oh, I see. So, just to make sure I understand, let me try and repeat
what you said above, but worded differently.
I can find myself in this kind of situation:
1. A blob of data arrives and a read event is generated
2. read( ... ) is called, but does not read in all of the data
3. Another event is generated results in read( ... ) being called
again.
4. If all of the data has now been read, stop, otherwise return to #3
Is this more 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.
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.
I see. Thank you.
_______________________________________________
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