Streaming JPEGs, detect end of JPEG

I have created a java server, which takes screenshots, resizes them, and sends them over TCP/IP to my iPhone application. The application then uses NSInputStream to collect the incoming image data, create an NSMutableData instance with the byte buffer, and then create a UIImage object to display on the iPhone. Screenshare, essentially. My iPhone code to collect the image data is currently as follow:

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


if(streamEvent == NSStreamEventHasBytesAvailable && [iStream hasBytesAvailable]){
        uint8_t buffer[1024];

    while([iStream hasBytesAvailable]){
        NSLog(@"New Data");

        int len = [iStream read:buffer maxLength:sizeof(buffer)];

        [imgdata appendBytes:buffer length:len];
        fullen=fullen+len;

        /*Here is where the problem lies.  What should be in this
         if statement in order to make it test the last byte of
         the incoming buffer, to tell if it is the End of Image marker
         for the end of incoming JPEG file?
         */
        if(buffer[len]=='FFD9'){
        UIImage *img = [[UIImage alloc] ini开发者_如何学运维tWithData:imgdata];
        NSLog(@"NUMBER OF BYTES: %u", len);

        image.image = img;
        }
    }

}
}

My problem, as indicated by the in-code comment, is figuring out when to stop collecting data in the NSMutableData object, and use the data to create a UIImage. It seems to make sense to look for the JPEG End of File marker--End of Image (EOI) marker (FFD9)--in the incoming bytes, as the image will be ready for display when this is sent. How can I test for this? I'm either missing something about how the data is stored, or about the marker within the JPEG file, but any help in testing for this would be greatly appreciated!

James

You obviously don't want to close the stream because that would kill performance.

Since you control the client server connection, send down the # of bytes in the image before sending the image data. Better yet, send down # of bytes in the image, the image data, and an easily identified serial # at the end so you can quickly verify that the data has actually arrived.

Much easier and more efficient than actually checking for the end of file marker. Though, of course, you could also just check for that after the # of bytes have been received, too. Easy enough.

Of course, all of this is going to be grossly inefficient for screensharing style purposes in all but the unusual cases. In most cases, only a small part of the screen to be mirrored actually changes with each frame. If you try to send the whole screen with every frame, you'll quickly saturate your connection and the client side will be horribly laggy and unresponsive.

Given that this is an extremely mature market, there are tons of solutions and quite a few open source bits from which you can derive a solution to fit your needs (see VNC, for example).