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.
Related
I have a source computer with a screen capturer on it sending screenshots via HTTP to my WCF service as multipart-form data POST requests.
The WCF service must forward this stream to another remote web service (running on php). I have to use this WCF because it is the only way to bind these two points together (different net interfaces and I can't use MVC controller because it is windows 2003 server and .net framework 4).
Here is the WCF Interface
I got the IncomingRequest so far when I start WCF and send screenshot from source handler. And stuck..
Could anyone tell me please if it is possible to forward Stream fileStream as it is to the destination point without its turning back to the multipart-form data and then again sending further as brand new multipart-form data request?
NOTE.
The end point receives the same multipart-form data by POST request. It means if I was able to run screenshots provider and target receiver on the same network interface they would do perfectly fine.
I have old windows service which only accept the UDP messages. In my modern code send only http request. Is it possible to convert http request to udp request and response with out using any external sources?
There is no such thing as a "UDP request" but only a UDP datagram without any inner meaning by its own. The service uses some application protocol (the "inner meaning") implemented on top of UDP . As long as this protocol not known it is unclear how a "converted" request should even look like and thus no conversion is possible.
As #Henk-Holterman points out, the type of Blazor implementation is important.
A Blazor WASM app can only do what a Browser+JS can do - UDP isn't supported. If you need to call an API via UDP, do it from a regular WebAPI method on your server which calls the UDP method using C# code.
If you're using Blazor server, just use a C# UDP method to make the request.
Sending UDP Packet in C#
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).
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.
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)