New protocol or another way?

Question

Hello everyone.
I made a client/server program which allows users to share their files on a local network (actually it works on the internet, as long as the IP is public). It has some features like download resuming and it lets users upload their own files onto other users PCs.
I've implemented a custom protocol (similar to ftp, I guess) which lets you browse through another user's filesystem as long as, his/her directories are shared (by setting them in the program itself, not shared via the OS, I hope it's clear).
Well, to request a remote directory contents, to request a download, an upload, a resume and so on, I'm using, as I said, my own protocol.
It is made of simple alphanumeric messages which are interpreted by a specific thread on the receiving machine which, then, responds with the appropriate operation.
My question is: is what I am doing, a good way to do that, or are there other more efficient and logical ways of doing it?
I tried using RMI but you need to setup the server specifically before using it.
My program is a simple one. It loads and works as a server and a client at the same time, and it doesn't request any specific knowledge as rmi does.
Any suggestion?
Now it works fine, but I don't think this is the best and standard way of putting things. I'd like to keep it easy. Users shouldn't be requested to accomplish hard operations to make this program work.

Answer 1

I don't mean to discourage you. I'm actually a big fan of RMI. I'll repeat what I said in another posting:
Initial organization to use RMI is a major pain in the butt. Lots of fiddling with compilers and paths and jars. The documentation is pretty fragmented.
The actual application coding is a dream, because it is all pretty much "just java".
This last point may have a bearing on which way you go, because if your application expands its functionality, your prototcol elements will also have to expand. I suspect that they will expand much less if you use RMI, because most of the handshaking is done for you.
Let me describe one application for which we use RMI.
My company provides a system based on distributed servers, each supporting multiple clients. One aspect of this system is a large library of files to be kept in synch on each server. "In synch" by and large means "identical". There are updates to the library of files, changing some small but significant subset.
We implemented a "pull" style change-distribution system: A service on each server polls for changes to a parent server, and when changes are detected, the child server selectively downloads the changed files, updating its library. One other complexity: The servers may be cascaded, i.e., organized in a multi-tiered fashion for library update.
All of this has been implemented using RMI. The hard part of the design is the overall control design. (Example of an item we are still working on: how to detect file deletions; this can be an issue if some portions of the library on a server are locally maintained.)
The actual file transfer is pretty trivial; we implemented a simple RemoteInputStream - just using remote calls that return blocks of byte data - then wrapped each end in a ZipStream, which
o provides data compression.
o provides the file properties (name, size, date/time).
o provides crc checking.
Performance is respectable.
Don't know if this helps.