Jet/Access databases are file databases. This means Jet needs file I/O access to the MDB file, and furthermore every instance of Jet accessing the MDB needs access to a common LDB (lock) file.
RDS works by having a proxy back on the web server that connects to Jet where it does have file I/O access to the MDB. It can be a security hole as well, so typical IIS lockdown practices disable the capability.
True client/server databases often support connections using pipes, RPC, or other mechanisms that can operate over various network protocols such as TCP/IP. These can be accessed over the Internet, but it is generally considered a Bad Thing, primarily due to security concerns.
.Net Remoting is little help, because in effect it is an analog of DCOM RPC. Along with myriad other issues, a .Net Remoting client still needs to have a server application to talk to which in turn connects to Jet via ADO, etc. which finally must open the MDB as a file for I/O.
If you are able to write custom web applications that run on the web server you can do almost anything you want between the client and the web application. But an MDB file sitting in a folder on a web or FTP server by itself is a lifeless file, just like an image file or a HTML document. All you can do is download a copy or upload a new file over it.
More typical practice would be to partition your application into two tiers. One for the user interface, the other for the database access and general application logic, then glue the two together over the Internet or intranet by some mechanism like Sheco suggests, which then might well be .Net Remoting or any other technique (including streaming persisted Recordsets over a TCP socket). But... this means you need a Windows server supporting user-written applications of some form. If you are leasing space on some hosting service this may limit you to ASP and some subset of common components they choose to support - many permit ADO and Jet databases though.
Since you aren't relying on a web browser as the client almost anything goes. You can even have your client be a Telnet client from the server's point of view. One that connects, logs on, then runs a console-mode VB program or WSH script at the server to interchange data with. The console program at the server would have to have file I/O access to the MDB file via ADO, DAO, etc. to open it using Jet.
This is the same thing as using ASP at the server - just a bit more funky and less scalable because it is conversational rather than transactional. You don't see a lot of Telnet hosting on Windows servers.
