The other day, I asked a friend for some pictures of a concert and wedding that we both attended. Normally, for smaller files, he’d just send me what I wanted through Skype. However, as anyone who uses Skype will tell you, peer-to-peer transfer speed in the program is abysmal. Not wanting to set him up a FTP account to my website, I suggested that we make the transfer using BitTorrent. Assuming that you are using uTorrent and have the appropriate exceptions already declared in your firewall, here are the steps that you can take to share files between you and your friends:
- Figure out your Internet IP address. If you don’t know what yours currently is, try http://whatismyip.com/.
- Figure out what port uTorrent is using. Your current port can be found in the Options –> Speed Guide menu.
- In uTorrent, go to File –> Create New Torrent
- Select the file or folder that you would like to share
- In the trackers section, add the following:
- Under “Other” select “Start Seeding”
- Click the “Create and save as…” button.
- Save the torrent file to your disk
- Send the torrent file to your friend
- Have your friend open the torrent
Some of you may be asking why we added the local machine (localhost) as a tracker in step #5. Some routers act goofy and don’t forward data properly when you attempt to access the router’s Internet address from the local network. Because of this, your friend will be able to connect to your machine, but you won’t! In other words, “localhost” is for you and your Internet IP address is for your friends.
As an aside, we found that sharing a folder transferred significantly faster than the same folder compressed into a zip file. Sharing a zip file, we achieved a download rate of approximately 10 kbps. With the folder, my friend and I were able to achieve a sustained download rate of approximately 60 kbps. Not too shabby!
Occasionally, I pretend to be a Python developer. Thus far, my IDE of choice has been PyDev + Eclipse. Recently, I did a few minor upgrades to my development box that allowed my to upgrade from Windows XP to Windows Vista 64. Before I could begin using Eclipse, I needed to install the latest version of the JRE. Since I prefer to download native 64-bit applications, I selected the 64-bit version of Java. Now, I’m good to go, right? Wrong.
Unlike the 64-bit version of .NET, the 64-bit version of Java apparently requires developers to create special 64-bit binary versions of their code. However, in looking at the Eclipse download page, you’d never know that you needed a special 64-bit version (for Windows). Only after a significant amount of treasure hunting did I find the location of the 64-bit version, found here.
To sum things up, you’re better of downloading the 32-bit version of Java as the majority of applications that you’re going to want to run will only work with the 32-bit version of the JRE.
Recently, I’ve been experiencing the joy that is Windows Home Server. To be short, I’d absolutely recommend WHS to anyone with at least two computers in their house. Anyway, in an effort to reduce redundancy between my computers, I’ve centralized my “Documents” folder onto my WHS machine. For the most part, this experience has been awesome. Anyway, As this posts’ title alludes to, I sometimes get the following error when installing new applications: “Error 1327. Invalid Drive U:/” My “U” drive happens to be a mapped network share that points to my documents folder. Apparently, these applications don’t like networks very much! In order to solve this problem, I’m forced to manually remap all of my shares to a local folder. Definitely not cool.
If, by chance, you’re like me and recently installed Visual Studio 2008 onto a 64-bit version of Windows, you may be getting the following error when you attempt to debug an application:
The components for the 64-bit debugger are not registered. Please repair your Visual Studio 2008 Remote Debugger installation via ‘Add or Remove Programs’ in Control Panel.
The reasoning behind this error is discussed here. In short, because VS2008 is still a 32-bit process, it cannot directly attach itself to a 64-bit application (.NET defaults to 64-bits when you’re on a 64-bit OS). As such, VS2008 needs to use the remote debugger to bridge the 32/64-bit gap. Unfortunately, this feature isn’t installed by default! In reading the error message, you are lead to believe that this can be fixed by adding additional components from the VS2008 add/remove programs screen. However, in actuality, you’ll need to run a separate application (found in CD-DRIVE:\Remote Debugger\x64). After installing the 64-bit debugger, you should see this problem disappear.