Client requests the data from server (which has Asp.Net WebApi)
and server returns the result.
Is there a way to confirm that client actually received the response when you don't have the control of client (I mean, I can't make client to send the confirmation)
Possible scenario client lost its internet access before it receives the package.
HTTP protocol does no allow "client finished processing response" confirmation for single request. You need to build your own multi-request handshake.
Note: since you've mentioned "precisely for legal reasons" you need to consult lawyer before trying to implement solution.
Related
From my understanding, the beauty of signal R is that it takes care of the "handshake" between the client and server to determine the best form of communciation between them (websockets, long polling, etc). I understand that by default it does this at the /signalr route. I read that before this the handshake would be accomplished with an HTTP Get request with an Upgrade/Connection header specifying to upgrade to this new connection.
In my current application we support handling many HTTP requests in a RESTful manner. If we wanted to expose some of this data in real time rather than in this request response format, what would be the best way to determine if we should open a connection using signal R? Would checking for those headers still suffice? I just feel like that is a bit redundant since signal R abstracts that away.
Instead of this, would a solution be for the client to specifically invoke a hub method to kick off the streaming as soon as he connects to the proper endpoint?
TLDR: Need a way to open a signal R connection from a HTTP request, don't know the best way to go about that whether it be from requesting the resource with custom HTTP headers or by just navigating to the url resource and having their client invoke a hub method.
A typical example of using signalr is:
an html file using JavaScript to connect to a signalr Server when the page is loaded. we call this signalr client.
a signalr server written in c#. it can be a winform or console or service.
the signalr Server can call any dll, or webservices or webapi located in the same server, or even in different Server.
then, the client can call any function defined in the signalr server. the server can call any function defined in the client for a particular client or for groups of clients.
also, client x can call client y functions as well.
I would also suggest you create this index.html inside a Cordova project, so that your client can use this app using any pc desktop browser, or any mobile phone browser, or run it as an Android or iPhone native app, by using One set of client codes.
if they navigate to some url resource instead of receiving a response with json in its body we want them to be constantly in real time using signal r receiving data
I don't think this is possible with SignalR. Reason is that all SignaR communication is done through single route (xxx.xxx.xxx.xxx/signalR) + all SignaR connections are established using handshake (By client sending negotiate request to this route. Well maybe not all - not sure if negotiation is happening in case you initialize SignalR connection object with specific transport).
I have an intranet/extranet app which calls the server to do some VERY LONG calculations. The client should be able to keep surfing the site and doing his stuff, until a message pops up saying the calculation has ended and asking him if he wants to go back to the page to see the results.
If so, the client must be redirected to that page, the data must be retrieved the from the server and displayed. If the user cancels the action, the data set must be cleared.
How do I send a message to the client from C# and how do I catch it? Is it possible?
Thanks
Reactive Extensions (Rx) for .NET deals with exactly this kind of problem. It allows for "push" notifications of remote events.
Here is a blog post that introduces Rx over ASP.NET:
http://weblogs.asp.net/podwysocki/archive/2010/02/16/introduction-to-the-reactive-extensions-to-javascript.aspx
Here's an entire RxJS library:
http://reactive-extensions.github.io/RxJS/
Yes, sending messages from server to client via http possible with using web-sockets or longpolling technologies.
I'd like to determine whether the proxy at a given IP address is transparent or anonymous. Transparent proxies connect to websites with your real IP in headers like HTTP_X_FORWARDED_FOR or HTTP_VIA. I would like to check these proxies, but all solutions I found are developed to work on server side, to test incoming connections for proxyness. My plan is to make a web request to an example page via the proxy. How do I check the headers sent by the proxy, preferably using the WebRequest class?
EDIT: So is there some free web API that will allow me to do this? I'm not keen on setting up a script on my own small server that will be bombarded with requests.
Simply you don't need that headers. I could check transparency of a proxy by sending request to any get-my-IP site, if it returns my IP then it is transparent. If not then the proxy is anonymous. So steps are:
send request to any get-my-IP site without proxies
extract the IP from response as my local IP address
send new request to any get-my-IP site with the proxy
extract the IP from response and compare it with my local IP (step 2)
if(LocalIp==ProxyIp) then the proxy is transparent else it is anonymous
That is technically impossible since the client only sees what the proxy returns back to the client - the proxy can do whatever it wants when communicating with the target server and transform your request and the answer from the server anyway it wants...
To really know what the proxy does you NEED see what the server gets and sends back without any interference from the proxy...
The reason all solutions are server side is that the headers you're talking about are only passed from the proxy to the server and never back to the client again in the response.
In other words, if you plan to check for HTTP headers in the request from the proxy to the server, you either need to check them server side (as the solutions you found do) or actively pass them right back in the response to the client to check.
Either way, you can't just make a request to a random page and check the headers the server gets, the server needs to be involved in some way.
i'm making an asp.net website to support Json request.
Each request must send a message on a ESB (actually NServiceBus) but i'm struggling with response..
I can actually receive multiple request of same type so the website send similar messages of same type on the bus. How can I be sure that each message response from the bus goes to the exact "requester"?
How can I deal with slow or no bus response?
Take a look at the AsyncPages sample that comes with NSB. That demonstrates how you can use callbacks and the async support in asp.net to build robust message based communication from a website. Callbacks is there if you need to get a response back to the webserver that sent the request (command). It's often better to have the website only send messages off and then read the result from another data store (ravendb , sqlserver etc). That will give you the chance to get at the data even if the webserver goes down (callbacks are not persistent)
The problem:
How to send data to and from a RESTful web service to an android phone. The data currently is sent in bytes and there are multiple messages sent both ways until the entire message is sent (denoted by some delimiter in byte array). It is easy to send to the web service from android using a POST to web service. The service must now send multiple responses back to android.
I am wondering if this solution would work, or if there is something better?
Suggested Solution:
After a successful post to the web service from android, the android will receive an initial response from the post function call. This response will contain a message ID. Now if that response does not have the message delimiter, then android makes a call to the POST function again with a special parameter containing it's Message ID and the web service will return the next part of the byte array. This continues until the entire message is sent.
Thanks in advance for any help. Also to note, the web service knows the phone's IP address after the first message and we must keep this connection-less (so no sockets)
REST uses a simple Request/Response mechanism. The way http works is that you send a Request, and the server sends a Response back. What you are mentioning is behaviour more like Web Sockets. You should do a little research on web sockets. They allow you to make a connection with a server from the client, and then until the connection is severed, the server can send messages to the client.