Recently I talked with some developers, and they said that they call one endpoint from their front-end (web app) and that endpoint is a web socket. All their REST calls go through this connection. This solution was in Java. So I started wondering how they do that. How they dispatch the endpoint, what is the payload, etc. but in Asp.NET Core.
I am wondering is it possible and how.
I see this is very interesting topic. I found this useful- https://developer.okta.com/blog/2019/11/21/csharp-websockets-tutorial
You can do this in dotnet core using SignalR: https://learn.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-5.0
I think you're mixing two different technologies.
A REST endpoint belongs to WebServices and is an url, pointing to one or more methods in your code that can accept parameters and return results in XML/JSON format.
You can then fetch this url from your front-end and read the response.
An example of REST webservice is Google Maps API.
A Websocket, instead, is a continuous connection and works as a plain socket but between a webpage running on a client and another server application on another machine (i.e. the server).
It's used when you need an open tunnel with continuous exchange of data: chats, video and audio streaming, multiplayer games and more.
You cannot make a REST call to a websocket endpoint and if you want to use websockets you must write a server in C# (i use .net core). A console application.
I'm unsure what you are looking for exactly. If you want to start with websockets, this is where i started from:
Writing websocket server
Writing a websocket server in C#
For webservices:
Writing a web service in ASP.NET
Related
I'm new to gRpc and now learning this tech
I'm wondering if gRpc can replace SignalR for updating notification bar on my client-side app (React).
Is that the case? or should I keep using SignalR for this matter?
(I'm asking it just to make sure I understand the purpose of the gRpc tech, by few articles I read it's more a web API replacement and few others compare it to SignalR)
Thanks!
y-me
Assuming you meant browser-based clients, then NO you cannot use gRPC. The gRPC protocol relies on HTTP/2 framing and in particular the ability to send and receive HTTP trailers. While browser themselves can and do use HTTP/2, current browser APIs (XHR/Fetch) don't expose HTTP/2 semantics.
There is however an alternative protocol, gRPC-web, that supports a subset of gRPC functionality you can utilize from a browser-based application. Given that it is a different protocol, your server will need to support it or you will need to employ a proxy like Envoy that can translate gRPC-web calls to gRPC.
I can't answer your question has if it is usable for Server/Client communications, just offer some thoughts. SignalR is made for the purpose of real time communications between Client and Server because of it's adaptability, and gRPC by it's constraints (HTTP/2 and HTTPS) is more reserved for backend micro-services communications.
I'm trying to create a server based around the restful api (basically a client - server system which listens on a specific port but all the tutorials I've seen were using asp.net, some databases or not suited / too complex.
I've tried The Msdn Tutorial, That One CodeProject and That Other CodeProject Tutorial and also haven't found a simple solution here either.
I was thinking of a solution like:
Server listens on specific port for restful requests (Lets call it "ServerListener") and handles the request then in a static "CheckNumber" if its either positive or negative. It'll then reply to the client with the value "positve" or "negative" (depending on its value). The client then shows a MessageBox with the result.
The final idea would be having the server being proxied by an nginx server which handles the the encryption with the client and sanitizing the request.
Please check https://msdn.microsoft.com/en-us/library/windows/desktop/aa364510(v=vs.85).aspx
The Http API will give you the freedom to implement your server without Asp.Net, without WCF, and even without IIS.
Check my post, it contains several examples for simple REST server implementations, including C#, Java, PHP and node.js.
I am porting a PERL (.pl file) which is a socket listener, which is hosted on IIS web server. A PERL client just opens a socket connection to this PERL server and start transferring data.
What ASP.NET technologies (without webpage and webservice) is the equivalent of this PERL service. Is there a ASP.NET web template that is ideal to just add the websocket C# code and have it always up and listening to a port for incoming traffic and be hosted on the IIS (Just like the PERL file and its simplicity. I am not looking for WCF answer. And how would it be configured on the IIS?
Thanks
Theres a few options here, if the socket is HTTP based then you could have a peek at Custom Handlers, these transfer everythign through HTTP though. If you are looking for just a socket which doesn't handle HTTP then you're probably not going to want to do that in IIS/ASP.NET but rather a C# Service, have a peek at a C# tutorial for multithreaded services. You can easily port this code into a service.
The problem is that IIS is really designed to be a HTTP/HTTPS protocol so your trying to force it to do things it wasn't designed for, you could go down the route of custom ISAPI modules, and HTTP modules but again you'd be trying to fit a square peg in a round hole.
I want to build a web-based irc client with JQuery. I know I need to open a socket to the irc server. What I'm wondering is, is it possible to open a socket purely from server-side C# code? Or would the nature of a web application prevent this and I would have to write a service to run on the host machine?
Thanks for any help :)
Yes, you should be able to make a socket connection from server-side ASP.NET code. On the other hand, given that you'd presumably want a persistent connection to the IRC server (rather than a new one on every request), you may want to write a separate service anyway - you don't want ASP.NET recycling to kick in and wipe all your context, for example.
Your ASP.NET code could then talk to your service to find out what had happened since the last request for that user, etc.
One simple approach would be to setup a singleton WCF service which acts as the bridge to IRC. jQuery AJAX calls against that service could then post messages that were input by the user, as well as retrieve messages sent by other users.
I have implement the chat with ASP.Net by using the SingnalR for duplex communication.
What I really done consist on the following steps.
1) ChatHub.cs
I have write down all the logic to connect with the IRC server and connect to the channels, receive different messages and notification from the IRC server. I then send these notifications to my ChatHub client by calling the javascript call backs from the ChatHub.cs
2) Client.aspx
Simple HTML page and it is using jquery to register the callbacks from the ChatHub.cs
3) IRCDotNet.dll
I have used this library to communicate with the IRC Server.
Hope, It will help somebody. Here is the link to download the IRCDotNet.dll
http://ircdotnet.codeplex.com/releases/view/50639
I have a server client application.
The clients sends the server http posts with info every second or so.
The server is implemented using C#, there server doesn't need to respond in any way to the client.
Whats the easiest and most practical way to get this done? Is there some kind of library that is easy to use that I can import into my project.
Why not just use a regular old web service? It sounds like you have simple functionality that doesn't need to maintain a connection state. With a web service, you can simply expose the methods to your client, accessible via HTTP/S. If you're already using .NET for your client, you can simply add a web reference to your project and have .NET do the heavy lifting for you. There wouldn't be any need to reinvent the wheel.
You can use http.sys to create your own http listener without IIS or additional overhead. Aaron Skonnard has a good article here.
Because of certain limitations of uhttpsharp (specifically no support for POST forms and file uploads and it using threads to process requests), I've made NHttp available at github which supports full request parsing like ASP.net and processes requests using the asynchronous TCP model.