NSStreams Programa de bloqueo!

Question

Todos,

Lo he bajado hasta este punto mediante comentarios, puntos de interrupción, etc. El programa se bloquea en el código marcado.

-(void) initNetworkCommunication 
{ 
    CFReadStreamRef readStream; 
    CFWriteStreamRef writeStream; 
    CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)@"192.168.17.1", 2004, &readStream, &writeStream); 

    inputStream = (NSInputStream *)readStream; 
    outputStream = (NSOutputStream *)writeStream; 
    [inputStream setDelegate:self]; 
    [outputStream setDelegate:self]; 
    [inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 
    [outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 

    [inputStream open];//WHY MUST YOU CRASH HERE 
    [outputStream open];//WHY MUST YOU CRASH HERE ALSO!!?!? 

    NSLog(@"She be opened, sir!"); 
} 

no choque si comento hacia fuera ambas cosas, pero se bloquea si comento hacia fuera uno (por lo tanto es decir, están causando el programa se bloquee). No hay información que se publique en el depurador tampoco. Todo lo que hace es enviarme a main.m y me muestran

"Tema 1: Programa de recepción de la señal: 'EXC_BAD_ACCESS'

Gracias por la ayuda de antemano

Editar: Aquí está mi delegar método, pero ni siquiera se presenta la segunda línea activa en el registro.

- (void)stream:(NSStream *)theStream handleEvent:(NSStreamEvent)streamEvent { 

    NSLog(@"stream event %i", streamEvent); //this doesn't post in the log when stream opened... 

    switch (streamEvent) { 

     case NSStreamEventOpenCompleted: 
      NSLog(@"Stream opened"); 
      break; 
     case NSStreamEventHasBytesAvailable: 

      if (theStream == inputStream) { 

       uint8_t buffer[1024]; 
       int len; 

       while ([inputStream hasBytesAvailable]) { 
        len = [inputStream read:buffer maxLength:sizeof(buffer)]; 
        if (len > 0) { 

         NSString *output = [[NSString alloc] initWithBytes:buffer length:len encoding:NSASCIIStringEncoding]; 

         if (nil != output) { 

          NSLog(@"server said: %@", output); 
          //[self messageReceived:output]; 

         } 
        } 
       } 
      } 
      break; 


     case NSStreamEventErrorOccurred: 

      NSLog(@"Can not connect to the host!"); 
      break; 

     case NSStreamEventEndEncountered: 

      [theStream close]; 
      [theStream removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 
      //[theStream release]; 
      theStream = nil; 

      break; 
     default: 
      NSLog(@"Unknown event"); 
    } 

} 

Answer 1

Cuando hice esto en mi controlador de vista (y no en una clase separada) que funcionó a la perfección.

Answer 2

probar esto una vez,

NSInputStream * inputStream = objc_unretainedObject (readStream);

May be a casting issue

Answer 3

Tuve un problema similar donde mi aplicación se bloqueaba en la devolución de llamada de handleEvent con un gran número de streamEvent. Lo resolví asegurándome de inicializar los objetos de NSStream (entrada y salida) Y abro una conexión al servidor en el método de entrada del objeto NetworkClient que mi VC planea usar.

Answer 4

Lo que está sucediendo es que la instancia de la clase de delegado se está desasignando (causando EXC_BAD_ACCESS en el ciclo de ejecución) ya sea porque no la retuvo, o porque está usando ARC (bastante probable) y no tiene una referencia a eso

La solución es o bien llamar a retener en la clase delegada, aproximadamente así:

SomeStreamDelegate *theDelegate = [[SomeStreamDelegate alloc] init]; 
[theDelegate retain]; 

O si tiene ARC habilitado, haga una variable de instancia en la clase en la que alloc el delegado, y almacenar su instancia de conexión allí. De esta forma, ARC no lo desasignará, porque la instancia var cuenta como referencia.

Answer 5

Si está utilizando ARC, echados los flujos de la siguiente manera:

inputStream = (__bridge NSInputStream *)readStream; 
outputStream = (__bridge NSOutputStream *)writeStream; 

Esto debería evitar el accidente. Y tenga en cuenta que si sus flujos son propiedad de un hilo separado del hilo principal, esto significa que el ciclo de ejecución debe llamarse manualmente utilizando el método run después de abrir los flujos.