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
Related
I have a webcam chat room application (so it's many-to-many video sharing) using WebRTC and a mediasoup server.
I am having problems with SOME of my users not being able to get an incoming video feeds to work. It's a difficult problem because I can't reproduce it at all, and I can't easily "remote-debug" the problem since most of my users are very non-technical. So far the only thing I can tell for certain is that it seems to be network-related, not browser-related, as I have had bug reports from people using Firefox, Chrome, Safari, and Edge. I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible. I just don't know what the exact problem is yet so I'm feeling around in the dark.
So, I'm trying solutions. I don't think(?) I have a TURN server set up but from what I have read, it seems like adding one certainly can't hurt, and could help with my situation.
I don't fully understand the entire WebRTC protocol or RFC 7118 (this stuff is really complicated!) or exactly what/where/how a TURN server fits into the bigger picture. It would help, right? A lot of Googling has led to no clear answers. Would love some help! Thank you!
WebRTC tries everything it can do to make a p2p connection, but there are times that it will fail. The turn server acts as a last resort so that the peers can both connect through the turn server. Obviously this is not a p2p connection, so there will be extra latency, and you will have to make sure that your turn server has enough bandwidth to cover all of the connections you expect.
TL;DR, If you need 100% connection rates, you should have a turn server.
I believe AWS has a ready made instance you can spin up, or if you could use this open source coturn server https://github.com/coturn/coturn
On a debugging note... Check your ice candidates type. You should see host and srflx if you only have a STUN server, but if you have a TURN server you will also see relay. You can replicate this issue by discarding the ice candidates that have host and srflx types.
I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible
That is websocket. The media traffic runs over UDP typically and mediasoup uses random ports. A TURN server which is configured on udp port 443 may help in some cases.
The other problem is UDP being blocked which is easy to reproduce with a local firewall.. Mediasoup supports something called ice-tcp which will allow media to run over a TCP connection. You should check if your mediasoup installation uses ice-tcp. If it does not, a TURN server with TURN/TCP will help.
My app communicates with an external server using AsyncSocket as a Client.
(the working code can be found here)
When the app starts, the user types in the IP address of the server computer.
assuming both iOS and server is sitting on the same subnet
Question: is there a way to "scan" the network for the server thus avoiding the user manual input for server IP ?
I can iterate the IPs one by one in a loop (10.0.1.x 10.0.1.x++)
yet it seems wrong and wasteful.
is there another more elegant way to do so?
I had an iOS project doing server discovery in the current (Wi-Fi) network. The typical solution is to use UDP broadcasting to ask for server info and then listen to a UDP response. As soon as you get the response with the server address you can establish connection using TCP sockets.
CocoaAsyncSocket is good enough for this. I used GCDAsyncUdpSocket and GCDAsyncSocket.
I understand you probably need more info on the topic. I'll try to extend the answer when I have time to.
WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).
I'm not trying to setup a VPN. I want to secure tcp sessions between services that might be implemented in either user-mode or as kernel daemons. If it weren't for the kernel requirement, TLS would probably suffice.
First target would be Linux; pointers to any example code in user or kernel mode would be dandy if there are any.
All the existing examples I've found are about creating VPNs and use a bunch of static configuration in protected directories, all of which I'd like to avoid. I imagine I'd looking at setsockopt things to define keys before listening and connecting, but have so far found nothing.
VPN will just offer you secure tunnel for your communication also this comes with price of slow connection or overhead. IF you are looking for Ipsec be ware that programatically trying to get a secure and chaning IP itself comes with the same price of large overhead for communication.
It is important to know that what is your specific need. Like if you are not bothered about overhead or extra cost, you can definitely go ahead do IPSec at Network layer. But if you are worried about the performance issues or you want less overhead in your communication SSL/TLS is better for offering you desired security.
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.