Writing and reading remote file

[Daniel Zuckermann]

Hello all,
I would like to store a file on a remote server that should be read and be written on from multiple clients, but I don't know exactly how to secure this file. On the server side I could make it accessible only from certain IP addresses, but what could be done on the Java-based client side? Maybe storing the file encrypted?
Thanks for any help.

[Paul Clapham]

In what ways do you want to "secure" it? Or to put it another way, what are the harmful behaviours which you want to prevent?

[Daniel Zuckermann]

I just want to prevent that an unauthorized person reads and writes the remote file. Hence, I need something like password protection and maybe also encryption. So the Java client has to submit username and password and encrypt and decrypt the file.

[Jeff Verdegan]

What protocol will you be using to access the file? If you're using FTP, it already comes with user/password access built in. If you're rolling your own, then you'll have to define how your server accepts the user and password and how it stores the user/hash (NOT password) combination.

If you want more concrete advice than that, you'll have to provide more information about what you're actually trying to accomplish and what context you're working in.

[Daniel Zuckermann]

I'm using a server that I don't own, so I have limited access, but instead of entering password and username manually to access a website on this server, I want the client Java program to do that. I will use the protocol that is easiest to handle.

[Jeff Verdegan]

Since you don't control the server, you're limited to whatever services and protocols it's making available to you.

Your subject is "Writing and reading remote file," but then you mention a web server. Web servers don't generally provide access to files, per se, and when they allow you to write to a file, it's just an upload to places one in a restricted area that you have access to.

Your last post and your first don't really fit together, so at this point, I really do not have a clear picture of what you're trying to accomplish or what your requirements, constraints, or use cases are. For instance, you don't own the server, but you say, "On the server side I could make it accessible only from certain IP addresses."

[Daniel Zuckermann]

I just want to rent some webspace, so I own the webspace and can upload and access data, but I don't own the complete server. On this personal webspace, I want to store a file that I can download from within a Java program, write on this file and then store the file again on the server.

[Paul Clapham]

Then following on from what Jeff said earlier, perhaps you should just rent something where you can use an installed FTP server which you administer.

[Ulf Dittmer]

The webspace would in all likelihood be accessible via FTP - you could use a library such as Apache Commons Net (which includes an FTP API) for upload and download of the file.

[Daniel Zuckermann]

Thanks, that looks very promising. Do I have any other options, maybe from java.net.* without using an external library?

[Ulf Dittmer]

I'd call Apache Commons Net the standard Java FTP client library. Is there any particular reason you wish to avoid it?

[Daniel Zuckermann]

No, I'm just wondering if there isn't any solution to this problem from the java.net library, because I searched quite a long time, but didn't find one. However, Apache Commons Net seems to be a very easy solution, so I will stick to that. Thanks for your help.

[Jeff Verdegan]

Daniel Zuckermann wrote:No, I'm just wondering if there isn't any solution to this problem from the java.net library, because I searched quite a long time, but didn't find one.

Apache Commons, and any other pure Java solution that you find, is built on top of java.net. So anything they do, you can write yourself using java.net.

But you still haven't answered the question: Why are you trying to avoid a 3rd party library?

[Daniel Zuckermann]

I don't try to avoid a 3rd part library.

What I want to accomplish is a simple, yet reliable highscore list without using a database. There are multiple options to achieve that goal: RMI, sockets and the Apache library. The users and their scores could be stored in a XML file.

[Paul Clapham]

So this file is going to be updated by more than one client? (Oh yes, you did say that in your original post. Sorry.) Then have you considered the possibility that two clients will try to update the file at the same time? The strategy of downloading the whole file and then updating the revised version leaves you open to race conditions. In other words, you don't want to do that because one of your requirements is reliability.

[Daniel Zuckermann]

Yes, the update mechanism must support multithreading, which can't be implemented without using any server side script. What do you guys think about the options I have mentioned?

[Paul Clapham]

Daniel Zuckermann wrote:Yes, the update mechanism must support multithreading, which can't be implemented without using any server side script.

Yes, that's right. Although your multiple negations are a little confusing, it's true that without using any server-side code you won't be able to implement a solution which supports multiple simultaneous updates. Or to put it more simply, if you want to support multiple simultaneous updates you're going to need something running on the server which protects against race conditions.

What do you guys think about the options I have mentioned?

I've already said what I think about using FTP. You mentioned RMI: if you were considering sending the update information from the client over RMI to the server, this might be made to work. However RMI doesn't work well over the Internet (you didn't mention whether this was a requirement or not) unless you have it listen on one of the well-known ports. Otherwise you're going to be fighting with people's firewalls. And there are simpler ways to achieve the same goal, which as I understand it is to send a game score to the server and have it integrated into a high-score list. A simple web service would work just as well and would run over HTTP.

You also mentioned not using a database. If it were me I would consider using a database, because if you store the raw data then you can produce a variety of high-score lists quite easily. And it makes the problem of atomic updates of the "file" go away.

[Daniel Zuckermann]

Thanks for your help. A database would be overkill, because this is just for learning purposes. I tried to avoid server-side code, because I wanted to test the code outside on a remote server, but there I can't start a Java server script. For this reason, I decided to test it locally by using the ServerSocketChannel class, which supports multithreading. The client sends a message (name and score) to the server and the server attaches this data to a XML file. However, I am not sure if I should send simple messages or better use objects, that wrap username and score. I would prefer the 2nd option and use XMLEncoder to store those objects in a XML file. When the client requests the higscore list, the server sends the whole list or maybe ten of the best players. Does this sound coherent?