I need to write a server that will handle a binary protocol with TLS. Nothing to do with HTTP or SOAP. But it needs to be able to accept incoming connections, with client certificates, maybe pooling, and provide responses. Ideally could also post messages back to the client asynchronously but not a requirement.
Can this be done with a special IIS plug in? or with WCF? Or is it best done by just listening on a raw socket?
Edit. To be clear, this is a binary protocol that is well defined by an industry standard. I do not want any software to interpret it, package things into objects etc. I just want to have a listener send bytes sent by a client to a class and then send them back.
I think Remoting can help you, you can make your own channel for example
Related
So I got as an assignment to make a small chat function where multiple clients should be able to connect to a server and communicate with it, the server should then be able to choose whom it wants to communicate back with. (From a dropdown list or something).
What I've been able to do so far, with help from some tutorials, is that clients can connect to the server and communicate with it but nothing more. The server can't communicate back.
I'm very new to this and have limited knowledge in both C# and TCP/IP.
https://gist.github.com/4565988 <-Contains both code for client and server.
So I what I need help with is a way for the server to reply to different clients and for the client to recieve a message from the server.
Any help is appreciated!
Best Regards, Fredrik
With regards to a starting point, I would have a look at WCF Duplex Services. Duplex allow you to subscribe to the service and send updates out using two-way communication.
Essentially you can create the server as a WCF service with a couple of methods: getclients and sendMessage. From there, a client can then subscribe to the service and (while connected) get a list of other subscribers (which you provide to the UI) and then send a message back to the service (which will then use duplexing to send it to whomever it needs to).
As long as you're not married to using sockets, this would be a lot easier than creating a protocol and managing a list of connections. There are also examples of using WCF as a chat medium available on code project.
For TCP knowledge I reconn Barbara Heckler's vid where she shows a brief implementation of such kind of server. Unfortunately in Java, but nevertheless very useful.
I reconn minute 0 - 15 for the basics (UDP) and 15 - 40 for the TCP connection and why mutlithreading is need for TCP but not for UDP.
http://www.youtube.com/watch?v=5QzNHEcLp10
It's pretty simple, really. That TCP stream you successfully extract and use to read what the client(s) sent can also be written to in order to send back something, so all you have to do is move the connection and stream objects out to shared collections of some sort so that your server-side sending logic can get at it when it wants to send something. Similarly, in the client you would issue a read on the TCP stream to read what the server sent.
I'm quite new to C# so please bear with me. I'm writing a relatively simple client server application in C# .NET 4.0. I am using TCP protocol, TCPListener and TCPClient to be more specific. I know how does TCP protocol work in theory. But I must be 100% sure that there will be no (unhandled) errors during data transfers.
After I send data how do I know whether data was successfully received. Can I totally rely on the underlying implementation of TCP protocol? So there is no need that I confirm from the other side that data was received?
It is crucial that I truly know which data was sent&successfully received.
I know it is a dumb question, but I really want to be sure. Thank you for your time and answers.
TCP guarantees that:
Data you send will arrive in the order you send it
Data you send will be received exactly as you sent it (unmodified)
No other (spurious) data will be received
It does not guarantee that rodents will not eat your cables, the power to the building will stay on, or even that the process on the other machine you are talking to will bother to do anything when the OS tells it that some data for it has arrived.
If you need a positive acknowledgement that data was received and acted upon, you need to send the acknowledgement back manually (since TCP connections are duplex, you already have a channel to do that).
Of course all of this does is not in any way specific to .NET, Windows, or any other implementation of a network stack.
Update: I 'd like to point out specifically that, after the OS network stack accepts data for transmission, there is no way for you to know that the process at the other end has received that data. The network stack knows in most cases that the data has reached the target (through TCP ACK messages), but it does not know if the OS on the target has fed them to the process they are destined for. So sending back your own "data received and acted upon" message is the only option.
With TCP/IP alone, you cannot determine whether any data is received - you would have to layer another protocol on top.
If you can find out if some particular data was received, then TCP/IP guarantees all data before that was also received.
There is no such thing as the '.NET TCP protocol'. There is just the TCP protocol, which has been running on the Internet for about 30 years. It's reliable. That was a design goal.
An option would be to use WCF Reliable Sessions over TCP. WCF reliable sessions will mask transport failures.
If you really need reliability AND network transport, why not use Message Queues? They have transactional guarantee (about as strong as the discipline of the developers working with it, but not stronger than that!)
It's like all your traffic with database-server-type safety (and ditto performance). I think you can easily configure .NET Remoting to use an MSMQ channel.
I've personally never done that, but I've used message queuing in general.
I've some fishy application that makes HTTP requests to a website, i would like to intersect that request and send other data to the server. Is that possible in C#,java or C++?
EDIT: The application isn't mine, i just know the endpoint that it sends http requests
Fiddler might provide the functionality you need. At the very least it may enable you to see what is being sent to the web site.
in Java You can intercept request from Filter
You may want to look into using an HttpModule, whose purpose is to intercept incoming HTTP requests.
The ASP Column: HTTP Modules
Firstly are you aware of how it is connecting to the internet? For example, is it using the settings from Internet Explorer, or is it establishing a direct connection? If the latter, this may be tricky, there is no direct port forwarding as there in Linux, so you'll need some third-party tools to redirect the traffic to a server (which you can write in Java, C++ or C#, I would go for C# if you know it for pure speed of development) In that server you can intercept the request, and then create your own to actually send to the real destination.
Sounds like a cludge, but I think you're stuck with this approach due to the lack of direct port forwarding. You'll have to configure the third-party tool that you use to forward someother well known port to 80, and your server should write to this.
After sending some tcp data with the blocking/non-blocking methods such as:
Socket.Send() or Socket.SendAsync()
How can I know that my data has received an ACK message?
Can .NET know if TCP data has been successfully sent?
The only way to know for sure is to implement some kind of application-level acknowledgement. The TCP level "ACK" packet is not exposed to the application level at all, so you have to use something more than that.
You make the other end respond to it.
Even if TCP has Acked it, if the receiving end terminates (for good or bad reasons) before processing the message and acting on it, you still don't know, so the only way to know is for the other end to tell you.
This information isn't available from .net's class libraries. I had the same kind of considerations when I started working on this port scanner in C#. I have made use of a .NET wrapper for libpcap (after installing the corresponding driver), the SharpPcap (http://sourceforge.net/projects/sharppcap/), in order to get this kind of information. The ACK packets are obtained through SharpPcap's interface (invoking the native libpcap interface's transparently).
My application is NScanner Port Scanner/Sweeper and you can find the code at codeplex, referencing to you my simple usage of the aforementioned library (http://nscanner.codeplex.com/).
I hope I helped.
"I'm trying to focus on how can you know when your data has been accepted by the other-side of the connection."
I think you need to be aware what type of application layer protocol you are going to implement and what impact this has on application performance.
Take HTTP as an example of a "Streaming like" protocol. A server posts a stream of data to a client. There are no more additional application layer "ACKs" and the server doesn't actually care when and how exactly his stream of data arrives. This is very efficent on high latency links.
Now compare this to SMB! Instead of streaming a file, data is partitioned into blocks. Every successfully transferred block of data is acked on the application layer. This gives you more control, however, it effectively kills the protocol on WAN networks (check out "Bandwidth Delay Product").
Taking this into consideration, you can come up with your own design for your custom protocol.
The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.
I recommend using Pcap.Net.
You can easily sniff packets using this library in C# and then easily check the packet values.
You can also easily build and send packets.
If you are really certain that you need to know the packet level details of your TCP connection, then in addition to creating the TCP socket for sending, you need your application to use the winpcap API to look at the raw traffic as well. You can install a filter to only receive packets relevant to the particular IP,port combination that determines your remote side.
There are a couple of projects out there creating .NET wrappers for libpcap, for example here
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.