Re: Steams vs Packets
Re: Steams vs Packets
- Subject: Re: Steams vs Packets
- From: Avi Drissman <email@hidden>
- Date: Sun, 14 Nov 2010 22:51:56 -0500
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> 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)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
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