Ubuntu – Are there other applications beside Nitroshare to send files between computers on the same LAN

What comes to my mind first is to use UPnP media file sharing between your machines. You will need a UPnP server on the machine that stores the files and a UPnP client to play the contents.

UPnP server/client technology is well established in Windows Media Player and allows media sharing over the network. If you are looking for a cross-platform solution there is e.g. VLC player or XBMC that can be installed on both, Windows and Ubuntu. However by using the UPnP protocol you can also run a different software on each machine (e.g. Media Player for Windows and VLC for Ubuntu).

To provide a UPnP server only to share media folders there is an easy to handle command line tool in Ubuntu: uShare.

If you rather like to send audio live streams simultaneously to all connected machines in your LAN you may want to have a look at Icecast available for both, Ubuntu and for Windows. This enables you to stream music using an internet radio protocol (but in your case streamed to local machines only - including so called "Internet Radios").

In any case you'll need enough LAN capacity for audio files to be streamed without congestion.

If you are on an Ubuntu version that is still supported, then your scp command will provide the -3 switch which enables copying files from remote1 to remote2 via localhost:

me@local:~> scp -3 user1@remote1:/path/to/file1 user2@remote2:/path/to/file2

You can also omit the -3 switch, but then you will need the public key (id_rsa.pub) of user1@remote1 in the file authorized_keys of user2@remote2:

me@local:~> scp user1@remote1:/path/to/file1 user2@remote2:/path/to/file2

scp then under the hood does a ssh user1@remote1 first and from there scp /path/to/file1 user2@remote2:/path/to/file2. That's why the credential must be distributed different from the -3 solution.

In other words:

• scp -3 remote1:file1 remote2:file2 transfers the file from remote1 to localhost and then back to remote2. The data travels remote1 → localhost → remote2. The localhost is the 3rd party in this scenario, hence -3. For this to work, you will need the credentials from localhost on both remote1 and remote2 because localhost connects to both of them.

• scp remote1:file1 remote2:file2 copies the file directly from remote1 to remote2 at the speed with wich they are connected to each other. localhost is not involved here (besides issuing the command). The data travels remote1 → remote2. For this to work, you will need the credentials from localhost only on remote1 but additionally you need the credentials of remote1 on remote2 because localhost connects to remote1 only and then remote1 connects to remote2.

If possible I would choose the second approach. As some comments already say: usually often the network cable between remote1 and remote2 is far thicker than the cable between them and localhost.