WCF supports several different protocols for communicating. My WCF services are deployed on the same machine only. I just wanted to know whether TCP is more effecient than HTTP or should i go with HTTP?
If your WCF services are on the same machine, use named pipes. I've found this flow chart helpful.
.
If your service will only run on the same machine, then try using NetNamedPipeBinding.
Of course, in any case, you should measure the performance you receive using realistic test data.
The advantage of HTTP - Application layer (7 in the OSI model) - is
close to user (human) usage, via text commands (and many responses)
one can use telnet (to a port where an application dialogs via http protocol) for instance and issue some simple commands to dialog with the remote server
the http protocol deals for you with otherwise complex actions
HTTP is (usually) based on TCP (transport) / IP (Network). Thus all the advantages described above bear a performance penalty. You could define yourself an application with a more flexible protocol (at the user/application level) but it usually requires more programming, like dealing with issues that were already included in HTTP. Also, as the name protocol implies, nobody will understand your own protocol if you define one, unlike http. You'll have to design, program and build not only the server side, but also the client side. Clients will have to install your program and use it.
HTTP is built on top of TCP, therefore TCP will be definitely faster. Also HTTP has to parse the text headers which is another bunch of time spent. If your use case allows that, go with TCP.
HTTP is a protocol on top of TCP, so it's most likely faster NOT to add an additional protocol on top. See also the OSI Model.
You can clearly see that HTTP is on top of TCP here:
http://en.wikipedia.org/wiki/OSI_model
OR
even better here:
http://en.wikipedia.org/wiki/TCP/IP_model
As has been said before, TCP is the transmission control protocol, HTTP is a protocol on top. You can create your own custom protocol that could be more efficient as it would not have some of the http baggage. I had to do this to grab frame numbers from a video stream being recorded on a remote computer.
Related
I've recently been passed an embedded project where an MCU uses libwebsockets (version 3.1.0) to setup a websockets client. The MCU is connected to a SIMCOM modem for 4g connectivity.
Up until now the communication was non-secured: SSL context not set and modem configured to provide just a TCP link to the server. The server URI was a wss one, but security was not enforced.
I've now been asked to set the communication to use SSL/TLS with server and client authentication.
Having never used libwebsockets before and being short on time, my idea was to:
a) Leave libwebsockets set as it was, so with no SSL context set up.
b) Configure the modem to creat an SSL/TLS context and connect to the server through that one.
I did this and I can see my device sending the request to switch from http to websockets protocol, as well as the server's successful reply (code 101). But my problem is that the server's reply never gets processed by libwebsockets and the connection is dropped after a few seconds.
I can se3 that the bytes that make up the server's reply are received by the modem and passed into the MCU's buffer used to pass data into libwebsockets, but then the library never calls its net_recv method to actually read from such buffer.
Also, libwebsockets is currently built with TLS support and uses mbedTLS as SSL/TLS library. But, as said about, SSL context is currently left disabled (ssl_connection in the connection info struct is left set to 0).
So, I was wondering:
Is my approach something that can work at all? Or should I setup the SSL context from libwebsockets and let the modem setup just a TCP connection?
If I were to setup the SSL context from libwebsockets, is there a way to pass certificates and keys tot the library as just C arrays? Or do I have to have them stored as files on a filesystem and then pass their paths to the lib?
Also, I should add that the MCU has a second connection to the server, an HTTPS one, that one too setup with client and server authentication and that works with no problems at all. Therfore, I'm sure that the modem is correctly configured.
If needed, I will be able to provide more info on library configuration and used from Monday, because I'm currently travelling and don't have access to the code. But I wanted to get the ball rolling.
Thanks in advance for your help.
Yesterday, finally I had time to look at the code again. It turns out that the problem was in my code (this was always a strong possibility).
The local implementation of the net_send had a bug and returned always negative values. Thus, libwebsockets thought that the HTTP request to switch protocol had failed and hence was closing down the connection.
So, to answer the two questions above:
Yes, it's possible to setup libwebsockets to not handle SSL/TLS and then provide a SSL/TLS connection from a lower layer (the modem in my case).
It is possible to store certificates and keys in C arrays of bytes and pass them to libwebsockets if you create a custom platform implementation for your platform and create a custom implementation of POSIX like methods (open, close, read, etc).
By default the library expects to work on a POSIX like filesystem, though. So, realising a custom implementation can be a bit of a job.
The above is true for libwebsockets version 3.1.0. I haven't used any other version of the library, so things might have changed since then.
All in all, I think that configuring libwebsockets to handle SSL and the TLS handshake and then provide it with only a TCP connection is the best way of using the library.
I chose a different strategy for the wrong reasons (tight deadline + not being familiar with the codebase), but I'm definitely planning on reviewing my approach at a later date.
I've installed Apache and I want to run an Apache webserver. I understand Apache is a HTTP Server but I wonder how can I force to use TCP or UDP when connecting to it. Should I configure ports on the server side? Should I use different ways to access the server on the client side?
The RFC specification of HTTP does say that HTTP can be run over other protocols than TCP, but this has never been done as far as I know. If you were going to try use another protocol for some reason you would need to choose one that has flow control like TCP does. UDP is not suitable.
Apache is designed to use TCP, and any change to this would require major changes to the source code.
I'm writing a server that needs to serve many clients. The traffic is NOT http (but rather some proprietary protocol on top of TCP). I'm not very familiar with commercial web servers such as IIS and Apache. Can anyone tell me if it's possible to write some sort of "extension" to run on top of one of these platforms so that I don't have to write the logic for the sockets? Or perhaps there is another way (not IIS or Apache) of doing it which is better?
My server is generally going to behave as a web service (gets request, queries db, sends response) however there is one scenario in which it stays connected to the client socket and sends updates at a given interval on that socket.
It seems reasonable for it to be a way to do this in a way that I'd only have to write my logic without the general logic of a server. Any ideas?
Thanks!
Good question, and its also good too look to leverage an existing web server - you get scalability and stability, effectively for free.
I've never done this myself, but it should be totally possible in IIS (i recommend v7+ for this, makes it easier).
You can set up a new web site through the administration tool, and assign it a port to listen on - this bit is pretty straight forward. You should set its Binding Type to net.tcp (this is a dropdown in the dialog to add a new website, you can't miss it).
You can then use either modules or handlers to implement the rest of your custom functionality. This article Developing IIS 7.0 Modules and Handlers with the .NET Framework is a good intro to the subject. Most of the doco out there about writing custom handlers and modules is focussed on the HTTP protocol, but there are some snippets floating around for TCP and/or net.tcp (because IIS and Apache are web servers, and web is synonymous with http). Another resource that may be useful is this: Configure Request-Processing for a Web Server (IIS 7)
Alternatively, you may consider changing your approach and do it as a net.tcp WCF service, with this you get the benefits of using IIS, the flexibility of choosing the protocol (can be statically configured, doesn't need to be compiled in), and you don't have to write handlers or modules.
I'm developing a filetransfer app in VB.Net
The sizes of the files vary, but can get up to 10+ GB.
I already create a chat app as a test.
On the clientside I run this code to connect to the server.
Dim clientSocket As New System.Net.Sockets.TcpClient()
Dim serverStream As NetworkStream
clientSocket.Connect("127.0.0.1", 80)
Can I also use this to transfer files?
I want the app to work through a firewall and stuff.
So I think I need the outgoing data on the client to go through port 80. On the server I want to be able to receive the data on another port (E.g. 8888). Is this possible?
And final question is. What protocol should I use for this purpose TCP or UDP.
Sorry for the three-in-one question :)
Thanks for helping me out.
Transfer Files: Yes you can very well use a reliable network stream to transfer files. Well at least the data of those files. You have to do the file system management (creating the destination file in the right folder, etc.) yourself.
TCP/UDP: As you need reliability and flow control to transfer big chunks of data over the internet, you might want to go for TCP. Also the other features of TCP like in-order delivery and error detection won't hurt. You would probably end up implementing all those yourself if using UDP, wasting a lot of your time.
Firewall: There shouldn't be a problem with firewalls on the client side of your application, unless they are really very strict and only allow outgoing HTTP connections. But the server port has to be accessible from the internet, that is you want your server side network configured such that incoming connection requests to your public IP and your chosen port are forwarded to the chosen port on your server. Look up "port forwarding" or "port NAT" for more information. Bypassing firewalls and NATs on both sides is really much more difficult if not impossible. Don't try.
In order to transfer extremely large files like you have, you are going to need to break them up into small chunks. This will help you set up an application that can resume after a network error. It is for this reason, as well as many others, that you also want to choose TCP for your transport protocol. UDP might be faster than TCP, but it doesn't have the error detection and correction you are going to need in order to have a safe transfer of data.
Here is a C# article on how to transfer large files from both the client and server perspective. If this is what you are looking for, you will just need to translate the code to VB.NET (which a translator can do automatically for your).
http://codetechnic.blogspot.com/2009/02/sending-large-files-over-tcpip.html
Basically, the code converts the file over to a byte array and then sends it across the network/Internet. Since you can choose the port you use, you won't have an issue with firewalls when you host this. On the client end, when the client initializes the connection, it will be an outbound initialization so it will go out of the network without any issue.
I assume you are on Windows, so just use BITS
There is a nice .net wrapper available sharpbits
In my office building we have laptops on multiple floors all running a WCF Service. When WCF services communicate with each other, will a message for an out-of-range device automatically reach it by multi-hopping? Does WCF/the WLAN device driver handle this? Or do I have to detect if a device is not contactable/out-of-range and implement hopping in my own service?
As long as you have a connection from your WCF client to the service - yes, all avenues will be used. You shouldn't have to concern yourself with things like what network path your messages take - the network just has to be present and stable for the duration of a call ;-)
There's nothing in WCF to deal with this, really - this should be handled way lower in the network stack, by the driver or the OS.
Short answer
With WCF can do either or both of these:
Rely on an underlying protocol like IP to handle roaming
Use custom channel code that handles retries, roaming, etc the way you want it
No special mechanism for enhancing roaming is provided in the WCF classes Microsoft provides, but the framework itself is easily capable of supporting this seamlessly if you write or find a channel implementation to do this.
Full answer
WCF is not an on-the-wire protocol. It is a framework that allows you to communicate using a wide variety of protocols and network stacks. This allows you to use the same client and server code whether you are using HTTPS, raw TCP, named pipes, or any other protocol.
WCF ships with many channels in the box, and you can add your own. For example if you want to communicate over BlueTooth or IRDA, just create a new channel that talks these protocols and you can use your WCF services over it. These channels can also be found online or purchased from vendors.
Most networking today is done using the IP protocol, and if you are using WCF to communicate between desktop machines you will probably be using some protocol(s) on top of IP, for example TCP or HTTP. In this case, IP's normal routing rules will be used, so if the two machines can exchane IP packets you can communicate using WCF.
So if your WiFi access points allow seamless roaming you will be able to tap into that functionality using WCF.
If your WiFi routing doesn't have seamless roaming, you will have to do some extra work if you want to maintain a connection during roaming. Specifically you will need to create a channel that will respond to a closed connetion by re-resolving the server nane and retrying the request. Of course you will have to use DNS or another protocol so the server can update its registration as its IP address changes.
WCF is flexible enough to allow you to create such a channel and use it without your application code ever realizing it. But nothing like this comes in the box: You would have to build it, or download or purchase it.
it has nothing to do with WCF....
if there is a connection between the computers, on the IP, then the message will get through...