How to enable file transfer for cross-platform application

I would like to enable file transfer between Windows PCs and a bunch of Linux devices within a corporate network(include one site or multiple sites). The file size can range from a few kilobytes to a few hundred of megabytes. I am hard to make a decision right now on the following possible solutions for file/data transfer:

  1. Using HTTP protocol.
  2. Using FTP protocol.
  3. Using Samba
  4. Any other file transfer protocol?

Any thought? Which one do you think will be the best solution for my task?

BTW, I think within a same corporate, I can visit a computer/device by its name such as "\\DeepBlueAtChicago" to access its resource instead of providing IP address, no matter the computer is running Windows or Linux, is it right? If so is this type of service thesedays more likely to be based on DNS or Active Directory or any other Directory Service?

Thank you!

Reply to
Like2Learn
Loading thread data ...

This is a really tough question without further details; there isn't really a "right" answer. What is the direction of file transfer (1 Windows server, multi Linux clients, multi Windows clients, multi Linux servers, ...), are you providing the software only on the Linux devices, and do you also require device discovery? Describe the architecture of the network in a bit more detail - i.e. who is connecting to whom - and it should be possible to suggest something helpful. Note: You will not, as a rule, be able to resolve \\SMB-NAME or SMB-NAME from a Linux box.

BTW, UPnP was designed to solve these sorts of problems for you (but it is far from trivial to implement).

Reply to
larwe

Good questions. I will try to answer as much as I can.

  1. I prefer that one windows PC polls multiple Linux device to get files. files will be transferred from the device to PC.
  2. I will write the firmware for Linux device for sure. I can also write PC software if it is required.
  3. I prefer the Linux device can be discovered by their serial IDs. I can consider discovery protocols such as zeroconf only if it is necessary for my task.
  4. Can you explain me the rule why I am not able to resolve \SMB-NAME or SMB-NAME from a Linux box? I will check UPnP, hopefully it will be a good solution. Thank you!
Reply to
Like2Learn

I think that everything you need is available in the free software world. You'd have to search for it -- good search terms would include words and phrases like "system administration", "network", "Windows", and "Linux".

What result do you get when you type "windows networking with Linux" in your favorite search engine?

When I first started using Ubuntu I just set up my Linux box to be a Windows server and everything worked peachy from XP -- with later versions of both Ubuntu and Windows things kinda broke, and I never bothered to fix it. But my understanding is that it's possible, if you want to learn how to flog it.

--
http://www.wescottdesign.com
Reply to
Tim Wescott

There are two tasks here - device discovery, and file transfer. These are independent, and should be treated separately.

First, think about device discovery or naming resolution.

The windows-style "\\SMB-NAME" system is part of the SMB protocol suite. It is available on Linux /if/ you have a SAMBA server enabled. When you refer to Linux "devices", I am assuming relatively small systems - samba is fairly big and resource-intensive. It also only works within a broadcast network segment, unless you have a WINS server setup.

Systems such as UPnP or zeroconfig work within a network broadcast, and don't necessarily work without extra client software on the PC side.

The easiest way to get things working is if you have a DHCP server on the network that works alongside the DNS server - this is a very common situation. If your Linux devices identify themselves to the DHCP server using their serial IDs, then those names should then be resolveable by the DNS server.

If you are using IPv6, your Linux devices can self-allocate an IPv6 address based on their IDs - then no naming service is needed at all.

Secondly, there is file transfer.

Samba works well on a Linux server, and is /fairly/ easily accessible from windows machines. But it is horrible to route over longer distances (if that is an issue for you). It is also not nice to have lots of devices filling up people's "neighbourhood network" when they are browsing for real servers on the network, it adds layers of complexity if they network has Active Directory or domain controllers (as most corporate networks do), and windows clients are not very efficient at connecting to lots of servers. And if you ever have need to connect to the same server from the same windows PC using different user names, prepare for a lot of frustration (or switch to Linux on the clients!).

FTP and HTTP are quick and easy on both the server side and the client side, as long as the files are coming from the server. Upload to the server is also easy for FTP, but more complex if you have HTTP. If you are sometimes transferring large files, make sure your setup allows paused or broken transfers to be resumed.

You might also want to consider security in all this. FTP and HTTP should be easy enough to secure.

A more imaginative method is to use ssh on the devices (highly recommended as a "backdoor" access anyway), and use scp to copy files.

Other ideas include having an additional Linux server as a collection point. The devices could contact that server (thus avoiding any discovery issues on the individual devices) and transfer files to it. That single server could have Samba enabled, so that the clients connect to the one server and view all the devices as directories within the one shared area. This would also isolate the needs of the clients from the needs of the devices - the devices could then use low-overhead and easily-secured ssh for file transfer, while the windows clients would see the data using windows-friendly SMB.

Reply to
David Brown

n
a
r

Very nice. I agree with most.

Reply to
Like2Learn

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.