Re: Steams vs Packets
Re: Steams vs Packets
- Subject: Re: Steams vs Packets
- From: Gordon Apple <email@hidden>
- Date: Mon, 15 Nov 2010 11:21:39 -0600
- Thread-topic: Steams vs Packets
Title: Re: Steams vs Packets
I am going back to treating it as a continuous (possibly incomplete) byte stream with circular buffers. Like I said, I have done that in the past and even have a patent (expired) on similar techniques. I was just hoping for a simpler solution. It looks like Dave Mark’s book (third in series) adds some categories which do what I need for sending NSData objects over a network. Thanks for the comments.
On 11/15/10 1:02 AM, "Avi Drissman" <email@hidden> wrote:
I haven't seen WiTap. However, note that one-byte messages are self-framing.
With regards to your comment on "some kind of internal time-out", that's probably Nagle's algorithm.
I don't want to be mean, Gordon, but from what you've written, your mental model of how the networking stack works is very different than the reality of TCP/IP and you seem shocked when the difference causes you difficulty. I highly recommend that you read a book on how to program using TCP and streams. W. Richard Stevens has lots of good stuff I can recommend.
Avi
On Nov 15, 2010, at 1:38 AM, Gordon Apple <email@hidden> wrote:
That’s what I suspected. Apparently, the WiTap example, which sends one-byte messages, must depend on some kind of internal time-out which sends a packet with whatever it has available (i.e., the one byte). I was hoping there was some way I could flush each message through as a single packet so that the receiver would always deal with precisely one message. I guess not. It looks like I need to go with the circular FIFO buffer, and use a header/length prefix on the messages.
I guess I’m surprised there isn’t a standard package or set of classes or methods for sending a NSData object. Actually, after Googling this subject, one of Dave Mark’s books seems to have covered this. I just ordered it.
On 11/14/10 9:51 PM, "Avi Drissman" <email@hidden <mailto:email@hidden> > wrote:
An NSOutputStream is exactly as it's named: a stream. An endless, undifferentiated, sequence of bytes.
If you need to send messages over that stream, you need to do the framing yourself. It's a stream; the chunks coming out of the stream are not controllable and are not necessarily the same ones that went into the stream (this may happen a lot, but it's not guaranteed and definitely something you must not rely on).
Avi
On Sun, Nov 14, 2010 at 10:38 PM, Gordon Apple <email@hidden <mailto:email@hidden> > wrote:
As stated previously, I'm trying to do a messaging system between iOS
devices, based (somewhat) on the WiTap example. It is basically working,
but with a few problems. Messages are sent as the bytes of an NSData. It I
send messages in quick succession, the receiver throws an exception when
trying to create an NSData from received bytes. Currently, to keep things
same, I'm trapping the exception and tossing the message(s) -- not elegant,
but at least it keeps it from crashing.
I'm depending on the number of received bytes to determine the length of the
NSData bytes. I suspect that "send" is writing more than one message to the
NSOutputStream and getting sent as a single packet. Is there good way to
control this?
If my supposition is correct, I suppose there are solutions. One might be
to monitor stream status until it quits writing, before sending another
message. This might also entail introducing a message queue. Another
solution might be to preface each message with a length measurement to
ensure reading only one complete message at a time at the receiver. Maybe
even a circular data buffer.
It appears that I need to set up a more sophisticated means to handle
messaging. I can do this if needed. (I have done comm protocols for NSA
and others in the past.) However, I was trying to keep this simple. I don't
fully understand how packets get formed using NSStream classes and sockets.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden <mailto:email@hidden> )
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden <mailto:email@hidden>
--
Gordon Apple
Ed4U
Little Rock, AR
_______________________________________________
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