First, thanks for your work on DC. I've been observing DC development since February, looking forward to the new client/server architecture.
Unfortunately the current implementation doesn't fit my needs - yet ;)
What I want is a true server which I can host in a remote data center. I'm very mobile, so I'd like to be able to connect to the server from everywhere - so usually I have to use a bandwidth limited connection and not a LAN.
Here are the obstacles I've encountered so far:
Server side user dir: It's a bit inconvenient that I have to initialize the directory on my local machine and then transfer an archive to the server. A simple directory initializer would be great.
Server credentials: I got totally confused about them. I thought the command line argument was to specify the credentials, not to provide it to the server. So I used -credentials:root/foobar at first, then I got an error. So next I tried -credentials:SA/12345 because of the usage text stating it as the first example. Last I tried -credentials:SA. A clarification in the documentation/usage text would be great.
Connection status in the client GUI: After launching the client I can't find any information on the operation mode. It would be good to see that a server is used instead of the local binding and whether it's up and running.
Encryption: The client/server communication needs to be encrypted.
Performance: Using a remote server over the internet is really slow. I would suggest to use one of the RPC frameworks out there. If you don't want to yous should at least compress the transfered data and do some connection management. The current ClientRequestHandler opens a new socket for every request. That introduces some unneeded overhead - connections can be reused. This would be even more beneficial in case you implement TLS sockets since this would increase the per connection overhead. I've monitored the network traffic when I changed from "User" to "Books" and the client made about 26 connections, transferring 808 KB of data. That's a lot. The surprising thing was that most of the data was formed by the requests. 750 KB where transferred from the client to the server, the response was just 58 KB. Since usually the upload is really slow on end user connections this is a problem. Using another RPC technology than just Java object serialization would also allow other developers to access the DC server API.
Hope my comments are usefull,
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great feedback, thanks! Did you also happen to read the client server manual as available for download from datacrow.net/#downloads? It explains a bit further on the requirements for starting the server and connecting the clients, etc, etc.
The server architecture has been a side effect of the restructuring I needed to do for the web server. I would not go as far as to say that it is gimmick but it has been more focussed on the use within internal networks. Depending on user requirements I can expand this functionality as I honestly had/have no idea whether anyone will be / is using it. I am glad that you have been working with it as it at least proofs one person is using it :-)
What I am focussing on now is the creation of the web server (which is quite far towards being finished as a first delivery). This would be far more usable for users wanting to have remote availability. Over the coming months / years it will have about 80 to 90 % of the functionality of the current Java version. I would advise waiting for this version for remote access. In the future this GUI will replace the Java client version completely (that's the goal) as Java Swing is not actively worked on anymore by Oracle. I am not a fan of the new GUI code they are currently working on. On the otherhand I have always been struggling with Java Swing to achieve acceptable performance and memory usage; the memeory handling for loading images for example is abysmal... For the perfomance of the client-server communication I am 100 per cent accountable though :-)
I am willing to make modifications, I would only request from you that you log each item as a feature request as I tend to loose track of requested functionality otherwise;
1. That could be easily achieved.
2. That is covered in the guide.
3. That's very true and could eaily be amended.
4. I don't really see a need for this to be honest. The web server will have full SSL capabilities.
5. I have left it as simple as possible and am aware of the side effects. Luckily the conversation code is very much isolated to a handful of classes which makes it easy for me to adopt. Reusing connections would be an easy optimalization. The other thing I have been thinking about is to use JSON for all communication instead of the serialized objects. The JSON requests could easily be encrypted as well and are very lightweight.
I will first finish the web server edition and for the 4.2 I could then focus on improvements on the thick clients.
Anyone else using the client-server architecture? Please join in to this discussion! :-)
All the best & thanks,
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where do you prefer to discus things? Because I disagree regarding #4. Every server which offers none public information should offer encryption. Form an information point of view there is no difference between accessing data through http or a Java ObjectStream. If the server is accessible from the net than I want the transactions to be protected. If you don't see a need for this then why do you mention SSL? It would be unnecessary as well. Even when you consider the fat client as a LAN only solution I don't want others to sniff on my passwords. I encrypt everything, even on a LAN. Defense in depth ;)
Regarding the credentials: It was not clear to me that the user dir created by the client already has a password set. And yes, I've read the guide, but I failed to understand it. Since in standalone mode the client doesn't ask for a password I thought the command line argument defines the password that the clients need to use. I was not aware that it has to be set in the client in user administration. Anyway, now I know how it works :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, thanks for your work on DC. I've been observing DC development since February, looking forward to the new client/server architecture.
Unfortunately the current implementation doesn't fit my needs - yet ;)
What I want is a true server which I can host in a remote data center. I'm very mobile, so I'd like to be able to connect to the server from everywhere - so usually I have to use a bandwidth limited connection and not a LAN.
Here are the obstacles I've encountered so far:
Server side user dir: It's a bit inconvenient that I have to initialize the directory on my local machine and then transfer an archive to the server. A simple directory initializer would be great.
Server credentials: I got totally confused about them. I thought the command line argument was to specify the credentials, not to provide it to the server. So I used
-credentials:root/foobarat first, then I got an error. So next I tried-credentials:SA/12345because of the usage text stating it as the first example. Last I tried-credentials:SA. A clarification in the documentation/usage text would be great.Connection status in the client GUI: After launching the client I can't find any information on the operation mode. It would be good to see that a server is used instead of the local binding and whether it's up and running.
Encryption: The client/server communication needs to be encrypted.
Performance: Using a remote server over the internet is really slow. I would suggest to use one of the RPC frameworks out there. If you don't want to yous should at least compress the transfered data and do some connection management. The current
ClientRequestHandleropens a new socket for every request. That introduces some unneeded overhead - connections can be reused. This would be even more beneficial in case you implement TLS sockets since this would increase the per connection overhead. I've monitored the network traffic when I changed from "User" to "Books" and the client made about 26 connections, transferring 808 KB of data. That's a lot. The surprising thing was that most of the data was formed by the requests. 750 KB where transferred from the client to the server, the response was just 58 KB. Since usually the upload is really slow on end user connections this is a problem. Using another RPC technology than just Java object serialization would also allow other developers to access the DC server API.Hope my comments are usefull,
Michael
Hi Michael,
Great feedback, thanks! Did you also happen to read the client server manual as available for download from datacrow.net/#downloads? It explains a bit further on the requirements for starting the server and connecting the clients, etc, etc.
The server architecture has been a side effect of the restructuring I needed to do for the web server. I would not go as far as to say that it is gimmick but it has been more focussed on the use within internal networks. Depending on user requirements I can expand this functionality as I honestly had/have no idea whether anyone will be / is using it. I am glad that you have been working with it as it at least proofs one person is using it :-)
What I am focussing on now is the creation of the web server (which is quite far towards being finished as a first delivery). This would be far more usable for users wanting to have remote availability. Over the coming months / years it will have about 80 to 90 % of the functionality of the current Java version. I would advise waiting for this version for remote access. In the future this GUI will replace the Java client version completely (that's the goal) as Java Swing is not actively worked on anymore by Oracle. I am not a fan of the new GUI code they are currently working on. On the otherhand I have always been struggling with Java Swing to achieve acceptable performance and memory usage; the memeory handling for loading images for example is abysmal... For the perfomance of the client-server communication I am 100 per cent accountable though :-)
I am willing to make modifications, I would only request from you that you log each item as a feature request as I tend to loose track of requested functionality otherwise;
1. That could be easily achieved.
2. That is covered in the guide.
3. That's very true and could eaily be amended.
4. I don't really see a need for this to be honest. The web server will have full SSL capabilities.
5. I have left it as simple as possible and am aware of the side effects. Luckily the conversation code is very much isolated to a handful of classes which makes it easy for me to adopt. Reusing connections would be an easy optimalization. The other thing I have been thinking about is to use JSON for all communication instead of the serialized objects. The JSON requests could easily be encrypted as well and are very lightweight.
I will first finish the web server edition and for the 4.2 I could then focus on improvements on the thick clients.
Anyone else using the client-server architecture? Please join in to this discussion! :-)
All the best & thanks,
Robert
Sure, I'll happily create feature requests :)
Where do you prefer to discus things? Because I disagree regarding #4. Every server which offers none public information should offer encryption. Form an information point of view there is no difference between accessing data through http or a Java ObjectStream. If the server is accessible from the net than I want the transactions to be protected. If you don't see a need for this then why do you mention SSL? It would be unnecessary as well. Even when you consider the fat client as a LAN only solution I don't want others to sniff on my passwords. I encrypt everything, even on a LAN. Defense in depth ;)
Regarding the credentials: It was not clear to me that the user dir created by the client already has a password set. And yes, I've read the guide, but I failed to understand it. Since in standalone mode the client doesn't ask for a password I thought the command line argument defines the password that the clients need to use. I was not aware that it has to be set in the client in user administration. Anyway, now I know how it works :)