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.
Related
I'm totally confused and stunned about my problem. I wrote a multi client server using sockets.
I created a first GUI that receives clients and display them in a gridview, in the click gridview event it opens a new GUI with the socket between the clicked client and the server. So everything about the connection between server and the clients go well and fast
But my problems are :
the send information between them like sending full process it sometimes shown full and it sometimes less result .
send files management for example when the server request full folders/files in a directory sometimes it shows them all and sometimes less result .
But the command such open a window open an url, send a message , commands like those works so perfectly and instantly .
I am so confused right now what's the problem
Notice 1 : I used the extern IP for connection between server/client.
Notice 2 : internet connection is perfect (definitely not slow)
I tried to use different buffer sizes, but what I'm really confused about is that sometimes the result comes full with a specific buffer size and sometimes not with the same buffer size .
Thank you for your time !
I would also recommend you use wireshark so that you are able to get the full information and transactions that are really going on in the network.
This will help you to rule out where the issue is coming from.
To determine the packet size see the image
Here I am not talking about how the TCP handshaking protocol works as I assume it is working. However do note that in the transmission if you see something like RST then maybe somebody issued a reset command implying that some error occurred in the transmission. Such as something due to checksum for example. Although it is generally a problem for someone working directly on TCP/IP protocol
This should help you confirm that you sent and recieved the correct length.
To begin with, why I've written a Telnet client is not important. It's my job and I have to do it. So, on to my question...
My Telnet client is simple and allows for both interactive communication (used by a human) as well as automated communication (used by a program). However, in order for my client to know when the server is done sending data so it can give control back to the user, I've had to hard code all of the possible command prompts for a given server into the client application. For instance, I create a list of prompts and then pass this list to the client so it can watch for these in the data stream from the server. When it sees that a data stream ends with one, it then gives control back to the user, who will enter a response or a command and send it. The client then watches again for any of these prompts and so on. The list could look like the following for a Telnet server running on CentOS:
private static void SetTerminalPrompts()
{
prompts.Add("login: ");
prompts.Add("Password: ");
prompts.Add("]$ ");
prompts.Add("]# ");
}
This would be used like:
response = telnetClient.ReceiveUntilPrompt(prompts);
And public string ReceiveUntilPrompt(List<string> prompts) simply reads the data stream watching for a prompt from the list.
The problem is watching for these prompts. In a general case, the Telnet client will not know the server to which it is connecting. And it seems silly to attempt to create a complete list of possible prompts by guessing all servers to which the client may ever connect (even though I've found several examples and posts that say just that).
What I would like to know is how do the Telnet clients that come with Windows or Linux know when to give control back to the user? How do they know when the Telnet server is done sending data?
I'm working on an Asynchronous HTTP handler and trying to figure out if the HttpResponse.Write function blocks until it receives an ACK from the client.
The MSDN documentation doesn't specifically say; however, I do know that the MSDN documentation for the ISAPI WriteClient() function (a similar mechanism) mentions that the synchronous version does block while attempting to send data to the client.
I thought of three possible ways to determine the answer:
Have someone tell me its non-blocking
Write a low level TCP test client and set break point on the acknowledgement ( is this possible?)
Use reflection to inspect the inner workings of the HTTPResponse.Write method ( is this possible?)
Its not blocking, but can use a buffer and send them all together.
Try to set HttpResponse.Buffer=false; to direct write to your client.
You can also use the HttpResponse.Flush(); to force to send what you have to your client.
About HttpResponse.Buffer Property on MSDN
And maybe this intresting you: Web app blocked while processing another web app on sharing same session
HttpResponse operates in two distinct modes, buffered and unbuffered. In buffered mode, the various Write functions put their data into a memory region and the function returns as soon as the data is copied over. If you set Buffer to false, Write blocks until all of the data is sent to the client.
I'm trying to write an asynch socket application which transfering complex objects over across sides..
I used the example here...
Everything is fine till i try send multi package data. When the transferred data requires multiple package transfer server application is suspending and server is going out of control without any errors...
After many hours later i find a solution; if i close client sender socket after each EndSend callback, the problem is solving. But i couldn't understand why this is necessary? Or are there any other solution for the situation?
My (2) projects is same with example above only i changed EndSend callback method like following:
public void EndSendCallback(IAsyncResult result)
{
Status status = (Status)result.AsyncState;
int size = status.Socket.EndSend(result);
status.Socket.Close(); // <--------------- This line solved the situation
Console.Out.WriteLine("Send data: " + size + " bytes.");
Console.ReadLine();
allDone.Set();
}
Thanks..
This is due to the example code given not handling multiple packages (and being broken).
A few observations:
The server can only handle 1 client at a time.
The server simply checks whether the data coming in is in a single read smaller than the data requested and if so, assumes that's the last part.
The server then ignores the client socket while leaving the connection open. This puts the responsibility of closing the connection on the client side which can be confusing and which will waste resources on the server.
Now the first observation is an implementation detail and not really relevant in your case. The second observation is relevant for you since it will likely result in unexplained bugs- probably not in development- but when this code is actually running somewhere in a real scenario. Sockets are not streamlined. When the client sents over 1000 bytes. This might require 1 call to read on the server or 10. A call to read simply returns as soon as there is 'some' data available. What you need to do is implement some sort of protocol that communicates either how much data is being sent over- or when all the data has been sent over. I really recommend just to stick with the HTTP protocol since this is a well tested and well supported protocol that suits most scenario's.
The third observation might also cause bugs where the server is running out of resources since it leaves all connections open.
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