I'd like to write and read TCP Streams directly without any modifications by ASP or IIS. Is this possible?
Edit: Goal is to provide communication between a program and a server. Data exchange between them is less then 25 bytes per connection (in default case). So Headers will cause more traffic then the real data. I need to use ASP.Net because the owner of the server will not let me execute my programs.
ASP.NET even in IIS 7.0 with it's new integrated mode doesn't reveal the underlying socket to your ASP.NET application by default. I'm not sure if there's any hack or third party out there. I think as a web server (IIS 7.0) and web development tool (ASP.NET) using HttpContext and Response objects there are many things you can do like accessing underlying output stream via Response.OutputStream or closing the socket by calling Response.Close() as well.
Sure, try reading this tutorial to give you an outline of using TCP/IP sockets.
ASP.NET is a Web Framework built on the .NET Platform.
What you are asking for doesn't need a Web Framework. You can accomplish everything you need using plain old .NET without using any ASP.NET components.
Related
Actually I'm using node.js and socket.io to establish a socket connection. For some reasons I need to replace the server part with an ASP.NET application. Therefore I have to replace the existing socket.IO-server with a suitable .NET pendant.
From my understanding socket.IO as well as SignalR use websockets. So can I replace the socket.io-server with a signalR-server without or with even minimal changes in the clients?
Actually I tried to setup a SignalR-Server using the following example http://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-server
I'm able to connect to the hub when I use the sample code mentioned there.
But I'm not able to connect to this server using socket.IO or websockets in nodeJS. Maybe because of the magic with the hubs.
So is there any solution for an easy to use .NET package, hosted in IIS, that allows secured websocket-connections or secure tcp-socket connections between clients and my server. This solution should be quite standard so I can use Java or Node or anything else on client side?
I want to write an application that "listens" for a server push.. i.e the server can broadcast.. I want to do this via an open web request to a php page that holds a database vale in it and returns the database value.. so that if the database changes.. the value changes which means C# app knows to fire a initiation of some sort (in my case it's a "refresh" request) 99.99% of this work is done via this refresh request.. I only need to know.. ho w to implement the "trigger" or "event" from the server... the standard methodology for this (I know) is polling x seconds but I know that a proper event driven architecture is much nice..
Remember this is nothing to do with IIS ... This is a windows client C# exe that needs to "listen" to a web server.. are there any good code examples people know about?
HTTP is a request/response protocol - there is no "push". Common historic approaches to solve that are frequent polling and long-polling, but these days web-sockets are another option. You can use web-sockets from a client application: in .net 4.5 on Windows 8 / Server 8 there is an inbuilt client in the framework, but it isn't hard to write one based on raw TCP from the specification (or just look for an existing client library). Web-sockets supports bi-directional communications, so the server can spontaneously broadcast to the clients. Great for prompt updates.
You would of course also need a web-socket server implementation, but that is available for most platforms and toolsets.
I would like to have a client application and web application (or service, no UI) and I would like to connect to said web service from within my desktop application and to have two simultaneous network stream, one of them for uploading data and reading them on server and the other one for sending stuff to the client application.
I am not looking for a solution that uses anything more than that like WCF or anything, I just want a way to create connection between web server and my client application and exchange pure binary data. I would implement the protocol myself, I am not looking for any entities or encapsulation like WCF provides.
I don't even know what project type is the best choice here. I thought about empty ASP.NET application maybe that I'd upload on FTP but I have no idea what I should do next to make the application connectible to. I am not asking for complete solution of course, rather some articles that focus on how to make a plain and simple connection between server and client. I want server to be able to immediately update client and vice versa, that's why I am looking for a way to have stream.
Edit: I may as well say that the service is meant to be placed on ASP.NET hosting and I don't know how ports work on these, if there are any restrictions or anything.
"Web service" and "Network stream" are incompatible concepts. Web-services are (ideally) stateless and disconnected - so they work regardless of how the underlying network works. Messages are exchanged only from client-to-server and are encapsulated in HTTP request/response pairs. Hence "web service".
If you want to exchange "pure binary data" (as you put it) then you just need to work with sockets (or use .NET's TcpClient, which wraps up sockets in an easier-to-use API). ASP.NET would be inappropriate for this.
You can technically have an application that uses sockets that runs within an ASP.NET host process but this might not work depending on how security is set-up and it's also bound by the ASP.NET process lifecycle (so it is activated by IIS and can be shut-down or recycled at any time without warning).
You do not want to use ASP.NET Web Services for this (ASMX). That is a legacy technology, and should not be used for new development.
Why do you not want to use WCF? Do you believe it's too complicated? The thing about WCF is that it removes the complication of creating your own protocols.
Also, which version of .NET are you using? WCF get a lot easier to configure with .NET 4.0.
Here is simple duplex example using WCF.
Try it, check if performance you've got is enough, try to use alternative bindings ( like net.tcp). WCF is really neat tool to use. Once become more familiar with it you will love it.
Also check chapter on bindings in WCF from Learning WCF
Have a look at the MVC4 APIController. It works much like stock MVC except that methods return XML or JSON (or anything else you like).
Eg
/api/Users/Get
would could return something like
{
{"Username":"Bob", "Id":3},
{"Username":"Steve", "Id":4}
}
You can also return files and other streams by using special return types. You even get strongly typed, validated input through the use of models.
There's an example here which shows a full CRUD controller and sample AJAX calls from JS which you can replicate in your desktop app
I'm new at Visual C# and the .NET framework but have a fair amount of experience in LAMP development. I was wondering about the security of linq to sql communication.
Usually when doing it the LAMP way, measures such as using a service layer were used partially to increase the security of the system not exposing the database authentication details over http.
Having gone through a few recommended (by microsoft) linq->sql tutorials, it seems as if the client-side application (through a web application) is interacting directly with the database. This doesn't seem very efficient or secure....
I would like to know the following hings:
1) What measures exist in .NET to allow for secure communication between client-side and server side apps?
2) Are there any preinstalled service-layer frameworks to work with in .NET?
3) Is it possible to manually use http request methods (POST/GET) in order to send data from a c# web application to a remote SQL Server database?
In an ASP.NET application all the C# code you write is executed on the server(server-side), and after it is executed the page is sent to the client(browser). Client-side code refers to javascript. Database details are not sent to the client.
You could refer to a LINQ system as a "client" in relation to the database, but that would be like referring to the PHP part of a LAMP application as the "client" in relation to the database - completely true but slightly misleading. In terms of the overall client - the browser - LINQ no more exposes authentication details than LAMP does.
Which "client" do you mean here. In terms of the browser the main mechanism is that the browser doesn't know what on earth you are doing. It won't even know it is LINQ unless you're the sort of person who likes putting "Powered by..." images on your webpage. In terms of the client to the database, there are several authentication models (user/pass, NTLM, Kerberos and I think some more) and you can use SSL and IPSec on the connection between the webserver and the database server.
You mean like MVC and WCF?
Yes, there has been since SQL2000, see http://msdn.microsoft.com/en-us/library/aa226553%28v=sql.80%29.aspx though I don't think it's very popular. This has nothing to do with LINQ which would connect to SQL through 1433 using its native protocol, and perhaps be used to build a website that allowed restricted operations rather than manual manipulation of server over HTTP.
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.