Re: Messaging System
Re: Messaging System
- Subject: Re: Messaging System
- From: Gordon Apple <email@hidden>
- Date: Wed, 10 Nov 2010 16:12:31 -0600
- Thread-topic: Messaging System
It appears that the problem is that I was trying to send the NSData object
itself. Apparently, you can't do that. You have to extract the bytes from
the data object and send that instead, and then reconstitute a NSData object
from the bytes at the receiving end.
On 11/10/10 1:49 PM, "Gordon Apple" <email@hidden> wrote:
> Thanks. It now appears to be reading the correct number of bytes, but when
> I create the NSData object, then try to initialize the NSKeyedUnarchiver, it
> blows up. Console says:
>
> 'NSInvalidArgumentException', reason: '*** -[NSKeyedUnarchiver
> initForReadingWithData:]: incomprehensible archive.
>
> The NSData only contains two keys and two short NSStrings. I'm not using a
> root object, but my understanding is that it is not necessary.
>
> - (void)parseMessage:(NSData*)data {
> NSKeyedUnarchiver* unArch = [[NSKeyedUnarchiver alloc]
> initForReadingWithData:data];
> ...
> }
>
>
> - (void)handleMessage:(NSInputStream *)stream {
> uint8_t buffer[1024];
> NSUInteger maxLen = 1024;
> NSUInteger len = [stream read:buffer maxLength:maxLen];
> if(len != 0) {
> NSData* data = nil;
> data = [NSData dataWithBytes:buffer length:len];
> [self parseMessage:data];
> }
>
>
> On 11/10/10 3:19 AM, "Quinn "The Eskimo!"" <email@hidden> wrote:
>
>>
>> On 9 Nov 2010, at 17:56, Gordon Apple wrote:
>>
>>> We know the overall connection works. Unfortunately, we are not getting the
>>> buffer pointer, length shows 0, and "success" returns NO ("buffer not
>>> available"), so "parseMessage is not getting called. I'm not sure what
>>> "buffer not available" means.
>>
>> -[NSInputStream -getBuffer:length:] isn't typically used in network code.
>> You
>> should be using -[NSInputStream read:maxLength:]. Check out the
>> SimpleNetworkStreams sample code for an example of this.
>>
>> <http://developer.apple.com/library/ios/#samplecode/SimpleNetworkStreams/>
>>
>> I should stress that -getBuffer:length: is allowed to return NO at any time.
>> In the case of a socket stream, it always returns NO. Socket streams talk
>> directly to the kernel; there is no client-side buffer.
>>
>>> Messages are short enough that they shouldn't be split.
>>
>> This has me kinda worried. NSStream is a byte stream, so it can deliver data
>> to you in any sized chunks it wants. If you rely on it preserving message
>> boundaries, your code will work most of the time, and then fail mysteriously
>> under wacky and hard-to-predict circumstances.
>>
>> 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
--
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