I have a Python tcp server that has a iOS client. It is able to send data and receive, the only issue I am having is likely with encoding. I am trying to send a JPEG through TCP to the Python server and write the data to a JPEG on the server. The jpeg keeps corrupting.
Client Obj-C code:
[self.stillImageOutput captureStillImageAsynchronouslyFromConnection:videoConnection
completionHandler:^(CMSampleBufferRef imageDataSampleBuffer, NSError *error) {
NSData *imageData = [AVCaptureStillImageOutput jpegStillImageNSDataRepresentation:imageDataSampleBuffer];
UIImage *image = [[UIImage alloc] initWithData:imageData];
iv = [[UIImageView alloc] initWithImage:image];
[iv setFrame:[[self view]frame]];
ConnectionManager *netCon = [ConnectionManager alloc];
conMan = netCon;
[conMan initNetworkCommunication];
[conMan.outputStream write:(const uint8_t *)[imageData bytes] maxLength:[imageData length]];
}];
And here is the python (twisted) server code:
from twisted.internet.protocol import Factory, Protocol
from twisted.internet import reactor
class IphoneChat(Protocol):
def connectionMade(self):
self.factory.clients.append(self)
print "clients are ", self.factory.clients
def connectionLost(self, reason):
self.factory.clients.remove(self)
def dataReceived(self, data):
file = open('test.jpeg','w')
file.write(data)
file.close()
factory = Factory()
factory.clients=[]
factory.protocol = IphoneChat
reactor.listenTCP(2000, factory)
print "Iphone Chat server started"
reactor.run()
TCP is a stream-oriented protocol. It doesn't have messages (therefore it doesn't have stable message boundaries). dataReceived is called with some bytes - at least one, but how many more than that you can't really know.
You can't just treat whatever is passed to dataReceived as the complete image data. It is some bytes from the image data. Chances are dataReceived will be called repeatedly, each time with some more bytes from the image data. You have to re-assemble the data passed to these multiple calls into the complete image data.
Related
I am quite new to OCaml and I am working on a small TCP client utility, using Async/Core.
The connection is opened using
Tcp.with_connection (Tcp.Where_to_connect.of_host_and_port { host = "localhost"; port = myPort })
I need to be able to accept keyboard input, as well as read input from the socket. I use the Deferred.any for this purpose.
Calling Reader.read reader buf on the socket results in `Eof, which is OK, but when the method (containing the Deferred.any code) is called recursively, I get an exception:
“unhandled exception in Async scheduler”
(“unhandled exception”
((monitor.ml.Error
(“can not read from reader” (reason “in use”)
.....
Reader.is_closed on the reader returns false.
How can I “monitor” the socket recursively without this exception?
Michael
I have a problem with QWebSocket connection with C++.
QWebSocket *mWebSocket = new QWebSocket();
connect(mWebSocket, SIGNAL(connected()), this, SLOT(connected()));
connect(mWebSocket, SIGNAL(disconnected()), this, SLOT(disconnected()));
connect(mWebSocket, SIGNAL(error(QAbstractSocket::SocketError)), this, SLOT(error(QAbstractSocket::SocketError)));
QNetworkRequest lRequest(QUrl("wss://gateway-predix-data-services.run.aws-usw02-pr.ice.predix.io/v1/stream/messages"));
lRequest.setRawHeader("Predix-Zone-Id", <my unique id>);
lRequest.setRawHeader("Authorization", <some token>);
mWebSocket->open(lRequest);
I am getting 3 errors and then disconnect, but never connect.
called slot: error
QAbstractSocket::RemoteHostClosedError
called slot: error
QAbstractSocket::ConnectionRefusedError
called slot: error
QAbstractSocket::RemoteHostClosedError
called slot: disconnected
When I make a small typo in my token (to test if authentication is ok), I am starting receiving only QAbstractSocket::ConnectionRefusedError error.
The most interesting part is that I have implemented websocket connection with python and it works very good, so the problem should not be from websocket server part, or request header setup:
import websocket
import thread
import time
def on_message(ws, message):
print(message)
def on_error(ws, error):
print(error)
def on_close(ws):
print("### closed ###")
def on_open(ws):
def run(*args):
for i in range(3):
time.sleep(1)
#ws.send('{messageId: 1453338376222,body: [{name: Compressor-2017:CompressionRatio,datapoints: [[1453338376222,10,3],[1453338377222,10,1]],attributes: {host: server1,customer: Acme}}]}')
time.sleep(1)
#ws.close()
print("thread terminating...")
thread.start_new_thread(run, ())
if __name__ == "__main__":
websocket.enableTrace(True)
ws = websocket.WebSocketApp("wss://gateway-predix-data-services.run.aws-usw02-pr.ice.predix.io/v1/stream/messages",
on_message = on_message,
on_error = on_error,
on_close = on_close,
header = {'Predix-Zone-Id:my unique id', 'Authorization:token'}
)
ws.on_open = on_open
ws.run_forever()
This websocket connection is part of of my c++ sdk, so I need it to be implemented with c++. Do you have any ideas what I have missed in my C++ code?
I am trying to spawn a server and connect to it on a different thread. I know Rust has blocking I/O, but I feel like I should be able to connect a server in a different thread. I do not have a lot of knowledge in threads. The end game is to connect to this server across a network. That is what I am simulating with the player_stream TCPStream. The player_stream will wait until there is something in its buffer. Once something has been written there, it will respond back to the server. As is, the program will not terminate.
use std::net::{TcpListener, TcpStream};
use std::io::{BufReader,BufWriter};
use std::io::Write;
use std::io::Read;
use std::thread;
fn main() {
thread::spawn(move || {
start_server();
});
let player_stream = TcpStream::connect("127.0.0.1:8000").expect("Couldn't connect");
let mut reader = BufReader::new(&player_stream);
let mut response = String::new();
reader.read_to_string(&mut response);
println!("Player received {}", response);
let mut writer = BufWriter::new(&player_stream);
writer.write_all("NAME".as_bytes());
}
fn start_server() {
let listener = TcpListener::bind("127.0.0.1:8000").unwrap();
fn handle_client(stream: TcpStream) {
println!("Client connected");
let mut writer = BufWriter::new(&stream);
writer.write_all("Red".as_bytes());
let mut reader = BufReader::new(&stream);
let mut response = String::new();
reader.read_to_string(&mut response);
println!("Server received {}", response);
}
// accept connections
for stream in listener.incoming() {
match stream {
Ok(stream) => {
handle_client(stream);
}
Err(e) => { panic!("{}",e) }
}
}
}
First off, don't ignore warnings. You have 4 errors of the type warning: unused result which must be used. Every single one of those could be cases where your code is failing and you wouldn't even know it. Use expect liberally!
Second, you have an open client read socket and you ask to "read all the data until the end into a string". What determines the end? In this case, it's when the socket is closed; so when is that?
Trick question!
The client's read socket closes when the server's write socket closes.
The server's write socket closes when the server's read socket closes.
The server's read socket closes when the the client's write socket closes.
So when does that happen? Because there's no code that does it specifically, it will close when the socket is dropped, so:
The client's write socket closes when the the client ends.
Thus the deadlock. The issue could be fixed by explicitly closing the write half of the socket:
stream.shutdown(std::net::Shutdown::Write).expect("could not shutdown");
Third, you are writing into a BufWriter. Review the documentation for it:
A BufWriter keeps an in-memory buffer of data and writes it to an underlying writer in large, infrequent batches.
The buffer will be written out when the writer is dropped.
The BufWriter is dropped at the end of the scope, after you've tried to read the response. That's another deadlock.
In the end, you need to establish a protocol for how to delimit messages sent back and forth. A simple but very limited solution is to have a line-oriented protocol: every message fits on one line ending with a newline character.
If you choose that, you can use read_to_line instead. I've also used BufWriter::flush to force the data to be sent down the wire; you could have also encapsulated writer in a block so it is dropped earlier or explicitly call drop(writer).
use std::net::{TcpListener, TcpStream};
use std::io::{BufReader, BufWriter, Write, BufRead};
use std::thread;
fn main() {
thread::spawn(start_server);
let player_stream = TcpStream::connect("127.0.0.1:8000").expect("Couldn't connect");
let mut reader = BufReader::new(&player_stream);
let mut response = String::new();
reader.read_line(&mut response).expect("Could not read");
println!("Player received >{}<", response.trim());
let mut writer = BufWriter::new(&player_stream);
writer.write_all("NAME\n".as_bytes()).expect("Could not write");
}
fn start_server() {
let listener = TcpListener::bind("127.0.0.1:8000").unwrap();
fn handle_client(stream: TcpStream) {
println!("Client connected");
let mut writer = BufWriter::new(&stream);
writer.write_all("Red\n".as_bytes()).expect("could not write");
writer.flush().expect("could not flush");
let mut reader = BufReader::new(&stream);
let mut response = String::new();
reader.read_line(&mut response).expect("could not read");
println!("Server received {}", response);
}
for stream in listener.incoming() {
let stream = stream.expect("Unable to accept");
handle_client(stream);
}
}
You'll note that the program doesn't always print out the server's response. That's because the main thread exiting exits the program.
You mentioned that your real case uses XML, which can have newlines embedded in it, making a line-oriented protocol unsuitable. Another common protocol is to send a length before sending the data itself. There are many possible implementations for this. At a previous job, we sent XML in this fashion. We started with an ASCII-encoded newline-terminated string of the length before the data itself. In that case, having the readability of the length as a string was a benefit. You could also choose to send a number of bytes that can be interpreted according to some endianness as a 2's compliment number.
See also:
Rust echo server and client using futures blocks itself forever
I would like to have a service which connects via TCP to a server and then continuously listens to incoming data. I'm using CocoaAsyncSocket which I'm using in the following way:
self.socket = [[GCDAsyncSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_main_queue()];
NSError *err = nil;
if (![self.socket connectToHost:#"..." onPort:... error:&err]) {
return;
}
[self.socket readDataWithTimeout:-1 tag:1];
and then in the reading delegate method:
- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag {
NSLog(#"%#", data);
[self.socket readDataWithTimeout:-1 tag:1];
}
is this correct that I'm immediately calling readDataWithTimout:tag: again? Or is there a (better) way to always listen to incoming messages?
For what you are doing this is fine. You need to call
-[readDataWithTimeout] in -didReadData, because otherwise you would only receive the first message from the server. GCDAsyncSocket is designed this way, because there are a few other ways you can receive incoming data.
Here's the situation - I attach some file (JPEG image) to the HTTP POST request so it should be sent to the local server via Wi-Fi and server should return some result (simple text).
Here's the problem I faced doing this in my Qt-application for Nokia N9 (Meego 1.2 Harmattan).
After request is sent, proceed by the server and answer is sent back (I can see log on the server) there's a huge delay (about 1 min) before data from server reaches the handset.
If answer returns in several parts - the delay is before first part and others are getting very fast (as it should be with the first one too).
The same code I use in the same app for Symbian^3 (Symbian Anna) on Nokia C6-01 and it works just fine - all the data returns in a couple of seconds (tested in the same network with the same server and request). Also I have several GET requests sending from this app to the same server and all of them works fine too. So it might be the only Meego problem.
Snippets:
void PostDownloader::sendPostJpgImage(QString url, QImage image) {
if(mainReply)
return;
char boundary[] = "AyV04a234DsHeKHcvNds";
image = image.convertToFormat(QImage::Format_RGB888);
QByteArray body;
QBuffer buffer(&body);
buffer.open(QIODevice::WriteOnly);
image.save(&buffer, "JPG");
buffer.close();
QByteArray b;
b.append("--").append(boundary).append("\r\n");
b.append("Content-Disposition: form-data; name=\"jpgfile\"; filename=\"camera\"\r\n");
b.append("Content-Type: image/jpeg\r\n");
b.append("\r\n");
b.append(body);
b.append("\r\n");
b.append("--").append(boundary).append("--");
QNetworkRequest req = QNetworkRequest(QUrl(url));
req.setHeader(QNetworkRequest::ContentTypeHeader, QVariant(QString("multipart/form-data; boundary=")+boundary));
req.setHeader(QNetworkRequest::ContentLengthHeader, QString::number(b.size()));
req.setRawHeader("Connection", "Close");
req.setRawHeader("Cache-Control", "no-cache");
req.setRawHeader("Keep-Alive", "1");
mainReply = manager->post(req, b); //POST
connect(mainReply, SIGNAL(readyRead()), this, SLOT(dataReceived()));
connect(mainReply, SIGNAL(finished()), this, SLOT(finished()));
}
So the delay is before calling the dataReceived() slot. How can this can be solved? What can you advice?
Thanks in advance.