iPhone / iPod ricevere messaggi dal server # tcpip C utilizzando CocoaAsyncSocket

Question

sto cercando di inviare / ricevere dati via WiFi ad un / app iPodTouch iphone da un server C # tcpip. per questo ho usato cocoaAsyncSocket dal progetto di Google. Se mi preme un pulsante e trasmetto una richiesta da ipod al server restituisce i dati richiesti (titolo del brano, per esempio) .. Voglio sapere ogni secondo che canzone è playng ... in modo da # server di C i inviare ad intervalli di 1 il secondo messaggio per la mia app. Nella mia app in un timer con l'intervallo di 1 secondo che io chiamo l'asyncSocket leggere readDataWithTimeout metodo. Il mio problema è che dopo 8-9 secondi che il metodo non è chiamato più. La connessione al server è ancora attivo e il server C # continua a inviare i dati ..

quello che voglio fare è la seguente cosa: -> winamp suona una canzone -> C # server richiede Winamp quali canzoni che sta giocando e invia il titolo della canzone per la mia app. -> iphone app riceve i dati e li visualizza

Non so il motivo per cui il metodo readDataWithTimeout non è chiamato più dopo un breve periodo di time..Maybe perché il breve periodo di tempo tra i messaggi inviati dal server C #?

Grazie, Sorin

Answer 1

L'ho fatto work..after un po 'più leggere ... in modo di leggere i dati quando si arriva con AsyncSocket su intervalli sconosciuti ho usato il codice di vuoto sanitario (non so se è la soluzione migliore, ma funziona per quello che ho voluto):

- (void) readDataFromSocket
{
        [socket readDataWithTimeout:-1 tag:0];
}

- (void)onSocket:(AsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag
{
    NSData *strData = [data subdataWithRange:NSMakeRange(0, [data length])];
    NSString *msg = [[[NSString alloc] initWithData:strData encoding:NSUTF8StringEncoding] autorelease];
    if(msg)
    {
        if([msg isEqualToString:@"something"])
        {
            Do stuff
        }
        else
        {
            Do something else
            }
        }
    }
    else
    {
        NSLog(@"Error converting received data into UTF-8 String");
    }
    [socket readDataWithTimeout:-1 tag:0];
}

io chiamo una volta nella mia applicazione del metodo readDataFromSocket che chiama le prese [presa readDataWithTimeout: -1 tag: 0] metodo. Dovrebbe essere chiamato una sola volta nell'arco app perché nel metodo - (void) onSocket: (AsyncSocket *) didReadData calzino: (NSData *) Dati withTag: (lunga) metodo di tag nell'ultima riga io chiamo di nuovo il [presa readDataWithTimeout: -1 tag: 0]; che racconta la presa di ascoltare sul socket. Quando i dati arrivano alla presa lo leggerà.

Spero che aiuta qualcuno ..

Answer 2

Molte cose qui. In primo luogo, perché fare questo ogni secondo e non solo sui cambiamenti canzone? Questo sta per essere molto costoso sulla batteria iPhone a chiacchierare costantemente in questo modo. Non c'è motivo di farlo anche su un desktop.

Quindi, se ho capito bene, iPhone si connette a .NET e chiede per la canzone. .NET restituisce la canzone e lascia socket aperto. Ogni secondo, .NET scrive alla sua presa, e ogni secondo iPhone legge dal suo zoccolo.

Quello che ho il sospetto che sta accadendo è che a un certo punto il timeout sul readDataWithTimeout:tag: non scade prima delle prossime incendi NSTimer (nessuno dei due ha alcuna reale garanzia circa quando scatta). È quindi probabilmente ottenere due chiamate readDataWithTimeout:tag: esecuzione allo stesso tempo, probabilmente ottenendo il delegato presa confuso.

La soluzione migliore è un "lungo sondaggio." Sul lato iPhone, chiamare readDataWithTimeout:tag: con un tempo abbastanza lungo timeout (diciamo 30-60s). Ogni volta che torna, proprio ciclo destra di nuovo in esso:

while (self.isRunning) {
    [socket readDataWithTimeout:60 tag:0];
}

Poi nel -onSocketDidDisconnect: e -onSocket:willDisconnectWithError:, assicurarsi di impostare self.isRunning a NO. Sbarazzarsi del NSTimer del tutto.

Mi piacerebbe ancora non postare nulla dal lato .NET fino Winamp cambia in realtà canzoni, però. L'invio gli stessi dati più e più volte non fa un favore.