I'm trying to send an image to wcf to use OCR.
For now, I succeeded in transforming my image into a byte[] and sending it to the server using wcf. Unfortunately, it works for an array whose size is <16Kb and doesn't work for an array >17Kb.
I've already set the readerQuotas and maxArrayLength to its maximum size in web.config on the server size.
Do you know how to send big data to a wcf server, or maybe any library to use OCR directly on wp7?
If all else fails, send it in fragments of 16Kb, followed by an "all done" message that commits it (reassembling if necessary)
Bit of a hack but howabout sending it with a HTTP post if it isn't too big? or alternatively changing the webservice so it accepts a blob? (the current array limitation is a limit on the array datatype in the W3C spec)
Finaly solved.
You have to update your web.config to allow the server to receive big data. And then you have to use the Stream type in your WCF and byte[] type in your WP7. Types will match and both WCF or WP7 will agree to receive and send it.
In WCF :
public string ConvertImgToStringPiece(Stream img)
{
//.....
}
In WP7 :
Service1Client proxy = new Service1Client();
proxy.ConvertImgToStringPieceCompleted += new EventHandler<ConvertImgToStringPieceCompletedEventArgs>(proxy_ConvertImgToStringPieceCompleted);
proxy.ConvertImgToStringPieceAsync(b); //b is my Byte[], more thant 17Kb.
I don't know if this works on WP7, but with WCF you can also use streams to upload bigger amounts of data.
You can try using a WCF session. The key thing to remember is that sessions in WCF are different than normal sessions we use for Internet programming. It's basically a call to a method that starts the session, any interim calls, and then a final one that ends the session. You could have a service call that starts the session, send chunks of the image, and then call the last one which closes the session and will return whatever you need.
http://msdn.microsoft.com/en-us/library/ms733040.aspx
Related
I want to use gRPC to share very large file (more than 6GB) between endpoints and a server.
The project where I'm currently working require a central server where endpoints can upload and download files. One of the constraint is that endpoints don't know each others, but they can receive and send messages each others from a common bus.
To implement this server and its communication with endpoints, I'm evaluating to use gRPC.
Do you think is the best solution for file stream? what alternatives do I have?
thanks in advance.
gRPC with client/server streaming is capable of handling upload/download of files.
However, there's a discussion here on the performance of gRPC vs HTTP for file upload/download, which says HTTP is any day going to be faster to upload/download because this is just reading/writing incoming bytes, while gRPC performs additional serialization/deserialization for each message in the stream adding significant overhead.
There is another blog doing some benchmark on the same - https://ops.tips/blog/sending-files-via-grpc/ .
If you are looking to implement something that has to handle scale, you can do some more research.
If you really want to do this over gRPC, then the key thing is to make the response "server streaming", so that instead of returning 6GiB in one chunk, it returns multiple chunks of whatever size you need, for example maybe 128kiB at a time (or whatever); you can so this with something like:
syntax = "proto3";
message FileRequest {
string id = 1; // or whatever
}
message FileResponse {
bytes chunk = 1; // some segment of the file
}
service SearchService {
rpc GetFile(FileRequest) returns (stream FileResponse);
}
but nothing is automatic: it is now your job to write the multiple segments back.
I suspect a vanilla http download-style response may be simpler!
I have wcf-service and wcf-client. Service send to client a big data array - 55000+ items for one request. Forming this array on service-side takes less then one second, but client-side recieve this array more than 5 seconds! Can I faster this? I use BasicHttpBinding on client-side, if in important. (Pagination is not good idea for me)
try using messageEncoding="Mtom" which must stream your data or if WCF client and server is yours change it to net.tcp binding the lower level protocol will get rid of the overhead data, and with it you could also stream the data
I have a .Net Remoting service that will return a class to the client application. That class has a string property where the string can range from 1kb to 400kb worth of data.
I tried passing 256kb worth of string from server to client and the client was able to get it in less than 5 seconds which is still ok since this call will only be used for trouble-shooting purposes by an administrator. However I read
here that when sending huge data: "the socket will be blocked from receiving all other messages until it receives the remaining .... packets". If my data ever reached an MB size I do not want to block the client from receiving other messages.
How can I achieve my goal of not blocking the client? Do I compress the string using GZipStream like in here? Or are there other better ways?
Good article from Tess Fernandez : https://blogs.msdn.microsoft.com/tess/2008/09/02/outofmemoryexceptions-while-remoting-very-large-datasets/
I am using the new PushStreamContent entity in MVC4 to stream notifications from my web server back to multiple listening iOS clients (they are using NSURLConnection). The messages being sent are JSON. When I send messages that are less than 1024 bytes, the message sends as expected. Sending messages larger than this size however causes the client to receive the message in multiple chunks, each being 1024 bytes.
I am wondering what is the best way for my iOS clients to consume these multiple messages coming back? Is there a way to have NSURLConnection aggregate the results for me, or do I need to implement something that gets a result, checks if it's valid json, if not wait for the next result and append the previous, and continue until it is valid? What is a better way of doing this?
I found that you are able to adjust the size of the buffer that writes data to the stream that PushStreamContent uses. However, chunking the data is the correct thing for it to do and keeping this small has several advantages. I ended up writing my own method to aggregate the data flowing in on the client side. See the following question for more details:
How to handle chunking while streaming JSON data to NSURLConnection
Is this possible? If so, what is the industry standard as far as software goes? Specifically, I am referring to .net controls.
Thank you
EDITED:
Here is what I need. I have a thin client with a balance where RS-232 is used to interact with the thin client. Currently, it is a compact framework app. What I would like to know id whether it is possible to have the same set up in a web application. So that would entail that the RS-232 is NOT the server RS-232 - it is the user's computer RS-232 - RS-232 is on the client. So when the RS-232 spits out input, it should go to the browser. Is it possible in a web application?
Two ways I can think of;
Buffer the serial data in an application object, and then use an ajax call triggered by a timer to grab and display the latest data.
For shorter streams of data, you could, instead of using asp.net controls per se, do something like;
Response.ContentType = "text/plain";
Response.Clear();
String serialData;
while(serialData = getSerialData() {
Response.Write(serialData);
Response.Flush();
}
This will write text content to the web browser in real time. You probably wouldn't want to keep this session open for too long though.
If you wanted to display the stream of data within another page, then just place the page with the above code within an iFrame.
Also note that the above would best be done in an ashx handler rather than an aspx page.
Sure, you can do it. You'd read from a System.IO.Ports.SerialPort instance, and output it via an HttpListener.
The trick will be knowing what you want to do with the page that the HttpListener serves up. Since data will be coming in on the COM port in real time, you'll probably want to buffer it between HTTP requests to your server, since otherwise, if you try to read the port without data waiting, you'll hang the listener. You can also miss data if you don't read it regularly and it fills the SerialPort read buffer.