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#
Related
Is this possible to make a tcp IP communication to receive any content which is waiting, from C# code on demand ?
There is a tutorial at http://www.codeproject.com/Articles/312530/Calling-Webservice-Using-TCP-IP-from-any-Programmi which utilizes tcp connection to consume a web service. You may want to check it.
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 am recently learning about web sockets in .Net and have just found SignalR which seems like too good to be true in terms of the abstraction of what connection to use and it seems like there are a few signalr clients in different languages which is awesome.
In my current project different resources are being exposed through a RESTful API, and from my understanding of websockets the client needs to upgrade to a web socket connection through a HTTP request/response. Does signalR handle all this handshaking going on?
If there is an initial request/response from a GET request to retrieve a certain resource but they opt to upgrade to a socket connection, does the server give them any sort of response besides the response saying it acknowledges to open up a web socket connection or is the handshake all that occurs before the information is live updated for that particular resource?
Do you think signalR is scalable as opposed to implementing this through a protocol like STOMP where there are a large number of client libraries?
You are making things too complicated. 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.
you can actually forget about Web sockets, signalr choose the most appropriate transport protocol for you. it will choose Web sockets if it is available in both the server and the client.
I am developing a game in Flex.
There are both AIR and Web versions of this game.
AIR app would connect to a server using a UDP socket on a port.
The purpose of the Web version is to allow users to play when they are at work, or on a computer behind some firewall/proxy that blocks some ports. So the web would connect to a server using http connection on port 80.
The server code answering the http connections would be a java servlet that uses BlazeDS.
But if any of you find it more easier to explain for a C# server code(webservices or whatever), it would be ok .
The server code answering the UDP requests would be a simple class listening for socket connections.
My problem is I don't know how to put UDP and http code together. If there are 5 AIR clients, and 5 Web clients, they all need to meet in the server in some common collection variable, so that I can update all clients with latest info.
Who is going to instantiate the class that listens for sockets? And when?
So to summarize:
1. Do I need a dedicated server to achieve what I want?
2. Who will instantiate the udp handling class and when?
3. Is it even possible to keep the udp handling class and the servlet for http connections together? If there would not be http, I wouldn't even need tomcat. But http and udp code need to stay together, so that I can update the players collection. Is it possible to instantiate the UDP handling class and tell it to listen for socket when the servlet is deployed on the server...or something like that?
Any advices are more then welcome.
Thanks in advance,
Miha
http and udp code need to stay together
No they don't. They are transport mechanisms for your game data, so they should be transparent. Your UDP and HTTP servers should connect to your game backend, in what way is up to you. It can be in-memory, by using HTTP and UDP (socket) modules directly from your backend code, or it could be using some sort of service (so you can let other channels talk to the same backend).
This game backend does not connect directly to the user but only talks to the UDP and HTTP modules.
Then from this backend you process messages you receive from both HTTP and UDP, and sends the response over the same channel.
Example:
AIR-client 1 sends a valid login message to UDP server.
UDP server forwards the login message to the game backend.
Game backend returns succesful result message to UDP server
UDP server forwards the result message to AIR-client 1.
Example 2:
Now HTTP-client 1, which happens to be already logged in, requests all users currently logged in. It does so over HTTP, to the HTTP server.
HTTP server forwards this request to the game backend.
Game backend returns information to HTTP server
HTTP server returns response to client.
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.