Getting Started FAQ

Do I need a static IP Address for my Rumpus server?

No, a static IP address isn't required, and Rumpus works fine when your external IP address is dynamic. A static IP address does simplify things, and is recommended when available, but dynamic domain name services such as DynDNS and No-IP can be used to direct users to your server, even when your public IP address changes.

Every computer connected to the Internet has an address. The address has the form "192.168.1.100", that is, four numbers separated by "dots" (periods). These addresses can be temporary, assigned each time a computer logs in to the Internet (dynamic addresses), or permanently assigned to the computer (static addresses). In either case, IP addresses are assigned by your ISP. Dynamic addresses are assigned each time users log in so that a handful of addresses can be used by a large number of people, in turn. Static addresses are assigned to one person alone, and are permanently associated with an individual computer or network.

When possible and cost-effective, a static IP address is preferable. If you don't have a static address, or don't know how to configure one, call your ISP. Normal residential Internet accounts usually don't include a static IP address, so you will most likely need an extended or business-oriented account. Again, only your ISP can help you with this.

If your server is connected using a dynamic address, the address will change every time you log in to the Internet. People wishing to connect to your server will not know the address to connect to, unless you tell them each time they need to connect. The solution to this is to obtain a domain name that maps to the current IP address of your server. The domain name will remain constant, and end users will always be able to enter the name to connect to your server. The name will simply resolve to your current IP address at any given time, so that users will always be connected to the right server. In addition to DynDNS and No-IP, other services are available. Google "Dynamic DNS" for lots of options.

How Do I Give My Server A Name?

The use of names, rather than IP addresses, for referring to a server is handled by DNS (Domain Name Service). If your company already has a domain name registered (let's say, "acmewidgets.com"), you can populate any domain name you wish within that space. For example, you could have "files.acmewidgets.com" or "uploads.acmewidgets.com" mapped to your Rumpus server. To set this up, contact your ISP or registrar (the company through which you registered your domain name). Adding another DNS record is usually very quick and easy.

Note that the name "ftp." (as in "ftp.acmewidgets.com") is also commonly used. However, since Web browsers will commonly assume your server is FTP only, they may not connect in the most efficient way when a user supplies a name that begins "ftp.". If you do define a domain name that begins "ftp.", consider populating a second record like "files." or "uploads." to use for Web access.

Domain names work very much like your local phone book. You use a phone book to find a phone number given a person's name. The domain name system (DNS) allows Internet clients to find an IP address from a domain name. Your Web browser, for example, doesn't actually connect to "www.maxum.com". It uses a domain name server to convert "www.maxum.com" to "216.168.37.116", and then connects to that address.

Domain names are unique, and must be registered. Again, your ISP can help you with this, or you can use one of the registration services such as register.com. Once registered, your ISP or registration service will handle adding your name to the domain name system so that your static address is returned whenever a client asks for your domain name.

What Is The Difference Between FTP and HTTP? Why Do Some URLs Begin "ftp://" While Others Begin "http://"?

Rumpus actually includes two servers: HTTP and FTP. HTTP is the "Web" protocol: All "Web" sites are run by HTTP servers. FTP stands for "File Transfer Protocol". FTP is an entirely different protocol from HTTP, and defines a mechanism for two computers to transfer files. The Web allows you to specify how pages will be displayed to a user, accept input from a user (via forms), and do everything else we typically associate with the Web. FTP does not allow you to specify an interface to be shown to a user, or present any information in a generalized way; It is strictly for transferring files, and the interface seen by the user is completely up to the FTP client being used. The advantage of FTP is that it is a complete protocol for managing files, allowing the client to create and transfer folders, delete and move files, and more.

Most Web browsers include elementary FTP services, though they are usually very basic and often buggy. After all, they are first and foremost Web browsers, which means they were designed to work within the HTTP protocol. Dedicated FTP clients like Fetch, Transmit, WS_FTP, CuteFTP and others do a much better job with FTP.

When you enter a URL that begins "ftp://" you are telling the client (a browser, for example) that they should connect via FTP. URLs that begin "http://" are Web URLs, and tell the client to connect using the Web protocol.

Since Rumpus includes both FTP and HTTP servers, you can usually connect using URLs that begin either "ftp://" or "http://". In practice, you should choose the protocol that is best suited to the client software being used. In other words, if you are connecting from a Web browser, then form the URL so that it begins "http://". When connecting via FTP client, begin the URL "ftp://". (Actually, most FTP clients do not support HTTP or any other protocol, so a full URL is typically not required and you should just enter the server's address.)

It is very common for people to have problems transferring files with a Web browser via FTP. This is, in fact, exactly why the Web File Manager exists. Rumpus has been optimized to be as broadly compatible as possible with all FTP clients, including Web browsers, but there is a limit to what can be done from the server-side to compensate for poor FTP client implementations. When using a Web browser, it is therefore almost always best to connect via HTTP. For true FTP access, recommend to your customers and users that a real FTP client be used to connect to your server.

Why do files lose their file type during transfer?

Any computer file is actually nothing more than a series of numbers. What gives these numbers meaning is how they are processed. An image file, for example, needs to be opened by a graphics program, an audio file by a media player, etc. Matching files to the appropriate application, based on the file type, is performed by the system. When a file icon is displayed incorrectly, or the file isn't opened by the correct application when it is double-clicked, a problem with the file's type has occurred.

When the system is unable to match a file to the correct application, you can do this manually by dragging the file icon onto the application. This forces the selected application to be launched and then explicitly told to open the file. However, in many cases, it is desirable to have file types preserved so that files will open correctly when downloaded to a client computer, or on the server after upload.

When a file is transferred across a cross-platform network (like the Internet), it loses its Mac-specific information, which includes its Finder info and resource fork. Finder info includes the file's type and creator codes, which the traditional Mac OS uses to match files to the applications that can process them.

To preserve Finder info and resources, the file needs be be transferred using MacBinary encoding, which Rumpus fully supports. Unfortunately, no Web browsers support MacBinary, but well-behaved, traditional FTP clients, like Fetch, do.

So, to transfer a file with it's resources and Finder info, you need to use a MacBinary capable FTP client, and make sure the file is sent with MacBinary enabled.

Most modern file formats no longer use resource forks. In these cases, just make sure that the filename has the correct suffix. OS X uses either Finder info or a filename suffix to match files to applications, so if you use the correct filename ending, the file should still be handled correctly after transfer, even if its Finder info is lost.

For files uploaded to the server, Rumpus will automatically apply the Mac OS type and creator codes to an uploaded file based on its filename suffix, using the table on the "File Types" window. When files are downloaded to a remote client, the "Content-Type" is sent to the Web browser, which in most cases allows the browser to select an appropriate helper application to process the file (or process the file itself).

Another option for preserving resource forks is to compress the file before transfer as either a ".zip" archive or some other stuffed format. As long as the tool used to archive the file supports resource forks, the resources will be compressed into the archive file, and will be restored when the file is extracted at the destination.

For more details, see the "File Transfer Basics" article in the Rumpus package.

Why can outside users connect to my server, but I can't from my own LAN?

On some networks, users on the LAN will be able to connect to the server using the external IP address or domain name of the server. On others, this won't work at all, due to how the network is set up and the router you are using.

In all cases, it's best to follow this rule: When connecting from one computer to another on the same local network, the local IP address of the server should be used. Only external users connecting to the server should use the external address or domain name of the server.

Whether or not local users can connect to a local server using an external IP address depends on the router and its ability to route the connection to an external IP address back to the LAN. Even when a router will do this, it is common for the connection to be routed up to your ISP and back down to the LAN. Local data transfers therefore take place across your Internet connection. Not only will this slow your local file transfers to your Internet connection speed, but it will unnecessarily consume bandwidth that would be better used completing transfers for remote clients.

So, when making a connection from one computer on the LAN to another, be sure to use the LAN IP address of the server, not the external IP address or domain name.

You can simplify this for local clients using a Web browser using a bookmark. In the browser on each client, just make a bookmark using the local IP address, and labeled as "Rumpus Server" or whatever phrase users use to refer to the local server. Rather than connecting to the server by typing any address, local users then connect simply by clicking the bookmark.

If it is absolutely necessary for local users to be able to refer to the server by the external domain name, you can add an entry on each client to the local "Hosts" file on each client. This isn't part of Rumpus, so for complete details Google "hosts file domain name", but here are quick instructions. (Note: these instructions are for Mac and Unix clients, but a similar process is possible for Windows clients as well.)

In the Finder, choose "Go To Folder..." from the "Go" menu. Open the folder "/etc".

Find the file "Hosts", and open it in a text editor like BBEdit or TextWrangler.

Add an entry like this:

    192.168.1.123    my.server.com

In this example, "192.168.1.123" is the local address of the server, and "my.server.com" is the domain name of the server.

Save the file.

With this change made, the specified server name will resolve to the local IP address, allowing the client to access the local server via the local address, but by using the external domain name.

© Copyright 2023, Maxum Development Corp.