7 ms·
For years I wondered about the insanity of the FTP protocol. Why take random ports at both sides? Did they hate firewalls? Some day, someone explained this a
by hyperman1 5y ago
For years I wondered about the insanity of the FTP protocol. Why take random ports at both sides? Did they hate firewalls?
Some day, someone explained this allows for a client(with low bandwith) to setup a transfer between 2 servers(high bandwith) with the data not moving through the client. I've never seen this usage and don't know any ftp package supporting this, but it's pretty neat nevertheless.
- com2kid 5y ago> For years I wondered about the insanity of the FTP protocol. Why take random ports at both sides? Did they hate firewalls? Simpler answer: because Firewalls didn't exist at the time!
- InvaderFizz 5y agoNot sure if that is why the multiport setup, but the process you are describing is called FXP[0]. I used it quite a bit back in the late 90s. 0: https://en.m.wikipedia.org/wiki/File_eXchange_Protocol https://en.m.wikipedia.org/wiki/File_eXchange_Protocol
- deleted 5y ago[deleted]
- Lammy 5y agohttps://en.wikipedia.org/wiki/FlashFXP https://en.wikipedia.org/wiki/FlashFXP supports it.
- pavlov 5y agoAnother one of those weird Wikipedia trip articles that starts out rambling in a way that would never pass the “no original research” test today, then hits you out of the blue in the last paragraph with a matter-of-fact statement.
- throw0101a 5y agoLFTP supports this on the CLI: * https://en.wikipedia.org/wiki/Lftp https://en.wikipedia.org/wiki/Lftp * http://lftp.yar.ru/features.html http://lftp.yar.ru/features.html See also: * https://en.wikipedia.org/wiki/Comparison_of_FTP_client_software#Protocol_support https://en.wikipedia.org/wiki/Comparison_of_FTP_client_softw...
- Ekaros 5y agoControl channel and data channel makes a lot of sense. And is arguably a simpler and more efficient way to transfer data. You set up transfer via one channel and then you don't need overhead of extra headers and other stuff on the data itself. Compare to HTTP 1.1 for example where you often carry bunch of headers around.
- chungy 5y agoFTP predates full-duplex. You simply could not receive and transfer on the same port, so two were opened for each task. FTP is a protocol from the 1970s before TCP/IP existed. It has a lot of warts and really shouldn't be used on the internet anymore. :)
- throw0101a 5y ago"Before TCP/IP" = NCP. > The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. Until 1980, FTP ran on NCP, the predecessor of TCP/IP.[2] The protocol was later replaced by a TCP/IP version, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification. * https://en.wikipedia.org/wiki/File_Transfer_Protocol https://en.wikipedia.org/wiki/File_Transfer_Protocol Unlike TCP or UDP, NCP was not duplex: > NCP preceded the Transmission Control Protocol (TCP) as a transport layer protocol used during the early ARPANET. NCP was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol. The standardization of TCP and UDP reduced the need for the use of two simplex ports for each application down to one duplex port.[1] * https://en.wikipedia.org/wiki/Network_Control_Program https://en.wikipedia.org/wiki/Network_Control_Program So the original transport layer that FTP relied on necessitated two ports, and when the move to a newer transport layer occurred the use of two ports was carried over for simplicity's sake. And several decades later that design still exists. > FTP needs two ports (one for sending and one for receiving) because it was originally designed to operate on Network Control Program (NCP), which was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol. * https://en.wikipedia.org/wiki/File_Transfer_Protocol https://en.wikipedia.org/wiki/File_Transfer_Protocol Per RFC 114, responses from the server are considered a data type: when a user sends a command to the server, sometimes the response is a status update ('MKDIR successful'†) and sometimes the response is the requested file. The data structure of the response has fields to say what's coming back on the data channel for the requested transaction. † MKDIR was not a command, just using it as an modern example.
- 5y ago
- theshrike79 5y agoFXP was the thing that made (and to some extent still makes) the warez scene possible. There were specific people whose main role was that they had access to one source server and one or more target servers. Without spending more than a few kB of their own bandwidth they could transfer files between big servers easily.
- Dylan16807 5y agoI'm sure it played an important role, but a[n optionally restricted] telnet account could do the same, right?
- rndgermandude 5y agoI remember doing this, transferred a few large (at the time) files from one server to another. There were definitely some clients which had this feature, but I cannot remember which one I was using specifically. If I remember correctly, I did this because the servers in question were some "free" webhosting things where you'd only get ftp access (along with http, of course), but no shell. I also remember talking to some people back in the day who regularly did that supposedly. Members of some minor warez group who uploaded new releases to one server and then used FTP to directly transfer files from one server to another to create mirrors. Then retransfer from the two servers that now had it to even more servers for some exponential growth.
- jcrawfordor 5y agoMany early protocols were designed under the basic assumption that any two hosts on a network could initiate connections to each other. This was, after all, the fundamental concept around which early computer networks were designed... as networks of equal peers. Unfortunately, this assumption has failed the test of time, as the "peer to peer" nature of computer networks has been fundamentally degraded due to widespread adoption of a more strict client-server model. Today, it is mostly not true that any two internet hosts can intiate connections with each other, and while seldom phrased this way the reality is so deeply embedded in our understanding of the internet that protocols designed under this assumption, while common, seem absurd. There are numerous reasons for this that range from security concerns to IPv4 exhaustion to the simple practicalities of the way that computer networks entered widespread usage. We should all wonder: is it a good thing that we have abandoned the peer to peer nature of networks?
- rasengan 5y agoIt is not good. Hopefully IPv6 is adopted globally soon.
- spookthesunset 5y agoIPv6 only ensures each device has a globally unique IP address. It does not ensure there is a firewall between one of those devices and their ISP. NAT’s might go away under IPv6 but firewall policies with “default deny inbound connections” will almost certainly not.
- ThalesX 5y agoI think there are efforts underway to build a more p2p internet. I've been trying to find the time to build some small experiment using https://hypercore-protocol.org/ https://hypercore-protocol.org/ (no affiliation).
- jcrawfordor 5y agoThere are many protocols which are "logically" P2P, but actually using the network in a P2P fashion is a different matter and much more difficult. Hypercore, for example, uses a "distributed hole-punching" architecture in which clients that want to communicate with each other discover each other using a DHT and then preemptively send UDP traffic to each other in order to cause NAT appliances on both ends to create connection tracking entries. Unfortunately this assumes that the DHT is up and running to serve as a "meet-me" point for these nodes to know about each other in the first place. In order for this to happen a DHT member needs to "bootstrap" by... contacting a "bootstrap node" which is basically a special centralized Hyperswarm server with a conventional DNS address and capability to accept inbound connections. This possibly surprising fact, that at the core of the P2P distributed system there is a centralized client-server service that provides the initial discovery information to begin participating, is pretty much universal to P2P systems because of the limitations the internet imposes. Removing this requirement would require a significantly more P2P-architected internet that allowed, for example, participation in arbitrary multicast groups from residential ISPs. There are both theoretical and practical (but mostly practical) challenges to doing this. In other words, the way the internet works, the only real way to begin to participate in a P2P internet protocol is to connect to a centralized service to provide initial peer hints. This is commonly referred to as an "introducer" or "bootstrap node" or "peer helper" or other terms depending on the P2P system. Hypercore and the Hyperswarm P2P network it relies on are actually unusually advanced in how much they minimize the need for an introducer, to the extent that a Hyperswarm node can completely forget about the introducer (it could go down) after initial setup and it will probably continue to work okay although there is a probabilistically small risk of a split-brain scenario. Older P2P protocols like Bittorrent and Tor have a greater dependency on centralized introducers and cannot operate without them even after initial startup (with caveats such as Bittorrent's support for Kademlia DHT, the same underlying DHT protocol used by Hyperswarm, which is in use by some Bittorrent nodes but not all for various reasons). For hypercore specifically the introducers are bootstrap1.hyperdht.org through bootstrap3.hyperdht.org. These are basically hardcoded into your client.
- YXNjaGVyZWdlbgo 5y agoFlashFXP was the most used client in the late 90s Warez scene because of the easy implementation of fxp. Private internet was still 56k or up to 128k with ISDN. Most of the scene ftp sites were hosted in universities. You transfered files from the US to a local university went into the library and downloaded it on a drive. What a trip down memory lane.
- icedchai 5y agoThe simpler explanation is nobody was using firewalls when it was invented. Throughout most of the 90's, many people had unfiltered IPv4 at their desktops. I had dedicated internet at home: no firewall... at work, same thing.
- nunez 5y ago100%. When Microsoft made Windows Firewall opt-out with Windows XP SP2, it caused SOOOOOOO many headaches. On one hand, no more rogue porn pop-ups during work! On the other hand, nobody knew what a firewall was and why trying to use Skype or whatever was such a PITA. It’s a bit of a shame that one simply cannot use the Internet without a firewall of some kind (unless you really like getting cryptoransomed in, like, 30 seconds)
- jjav 5y agoIndeed. Through the 90s at $JOBS, my desktop workstation has a public IP address and was directly on the Internet without any kind of firewalling. Sendmail ran locally and I'd send/receive email to/from the world directly on my workstation. Same for FTP, HTTP, etc. That's how the Internet was originally intended to operate.
- kazen44 5y agoi doubt firewalls even existed in any capacity at this time. routing packets in and of itself was already quite an CPU intensive task, analysing and blocking packets would be a whole other ballgame during the early days.
- 5y ago
- jjav 5y ago> Did they hate firewalls? What's a firewall? By that I mean, firewall wasn't a thing when FTP was designed.