Writing a simple multi client <-> server system in Corba.
I am stuck on unique identification of the client. Is there a mechanism in Corba, like some POA policy that would allow a unique user id to be generated by the server and carried along with all that clients communication.
Basically I have the system setup so I manually do this unique user ID. Client connects, server generates a key which is sent to the client and stored on both ends. A similar setup that you might employ in many environments. What I am asking is if Corba has its own mechanism for this that I can leverage.
CORBA doesn't have any inbuilt client ID mechanism that you can use, unfortunately. The main reason why CORBA never specified it is because it's difficult to define what a "client" really is: is it a process or a thread? Is it an entire tier or a single application instance? What about clients in the same process as the server? In addition, certain developers might want different behavior spanning any of those options.
Personally, I think that your approach of having the server dictate an ID for the client is fine, but keep in mind that it's basically a "session ID" approach, and that can be tough to scale horizontally. Make sure that you absolutely, positively need to ID your clients, because something as simple as client authentication via IIOP/TLS might not do the trick just fine.
Related
I have a concept of a game system that includes (preferably) Java server and multi-platform clients (Web, Android, iOS).
This is a 1vs1 player-vs-player realtime game. Servers performs a matchup of 2 players. So basically server needs to handle many matches containing 2 players. Both players alter same data, and each player should be updated in realtime with actions of other player.
Can you suggest me:
1) Server-side framework/library that would ease the implementation, as I would rather not start learning node.js from the scratch. :) Vert.x comes to mind.
2) Should clients hold the replica of the data, and alter it locally (meaning only data that is transfered are only commands, here I see JMS as good solution), or should only server alter the data and then send the complete data set every time change occurs?
3) How should the data be transfered? Considering the multi-platform requirement only thing I see viable are WebSockets.
4) An example/tutorial of server handling pairing of WebSocket connections? All I ever found are 1-to-1 connections.
5) Considering scalability, can you explain how could all this work in a distributed environment?
1) I don't think node.js is such big deal to learn. I would personally prefer a well known - broadly used framework.
2) If you are considering mobile, probably the first option seems more sound. You should consider send/push deltas during the game, and still provide functionality to retrieve the full state of the game in case the client disconnect and connect with same ID.
3) WebSocket would be the best option. Push approach, TLS option and well supported. Another option is the WebRTC data connection, that is peer-2-peer most of the times. I say most of the times because if one of the users is behind a dynamic NAT router or restrictive firewall, it won't be possible, and you will need a TURN (relay) server. Anyway, it is less supported than WS.
4) You should not "pair websockets". The WS connections just input commands to your logic, and your logic broadcast events to whoever it wants. Despite of being a 1vs1 game, probably you want to inspect the flow of events for further debugging or analysis. So consider WS as a transport, not as an entity.
5) Very, very, very broad question. But assuming that you are going to use WS, and that your application will be so successful that you will need multiple servers... assume that it is impossible to predict that two users will connect to the same server, so you should consider a message bus that allow to play users from one server with the users in other server. An EDA (Event Driven Architecture) would make sense.
For a college assignment I'm building a networked Java application using sockets*. My architecture must be scalable so I would like to have multiple servers available for my clients to communicate with.
My question is, how can a client know about all available servers? My first thought is for the clients to keep a (hardcoded) list of server IP addresses and select from the list. What is best practice in this case?
*We cannot use RMI.
Let's imagine your network provider's costs got too high, and you decided to switch. Boom go your IP addresses. I would suggest the judicious use of DNS, especially round-robin DNS.
Using a central tracker could seem like a good idea, but it itself must be scalable, akin to Google App Engine, or it will become a chokepoint.
Simply create multiple A-records for a given name, and your clients will randomly select one when resolving.
If you are unable to use DNS an IP list may be beneficial--with one change. All of the servers circulate updated copies of the list and if a server cannot be reached, another is tried until a connection is made(and the list likewise updated). When the list is found to differ from the existing one the client's list is updated.
You can use RMI stuffs, making primary and secondary servers.
Secondary server may be continuously polling primary, when primary goes down, secondary can register on naming services to take on. When primary comes back, it will register back making secondary go down... like that.
Regarding client to know server, client can ask servers using RMI for identity.
I need to secure the connection between my primary java app and my MYSQL server. Right now I have a class in my primary java app with the info about my SQL server (login details; user, password, schema etc).
I tried obfuscating that class but it didn't succeed. Then I heard something about calling an external java app with the connection info, and retrieve that info securely.
How can I execute such a thing?
Runtime run;
Process pr = null;
run = Runtime.getRuntime();
pr = run.exec("your program.jar");
pr.getInputStream().close();
InputStream eos = pr.getErrorStream();
and you can use a file to pass your info to the jar application
When dealing with a client/server style application, all the business logic, including the persistence layer, should be maintained on the server side.
That is, the client connects to some server process and makes requests. It should never care about how the data is managed or stored. It just cares about getting and manipulating the data. This also means that you centralise the business associated with that data, which means that should it change, you are less likely to need to change the client.
This also means that all the access information for the database never leaves the domain of the server.
Now the question is, how do you achieve. This answer will come down to exactly what it is you want to achieve an the means by which you want to achieve it, but, I would also add, the client should be authenticating with the server first, meaning that the user must be made to enter and user name and password in order to be able access the data (unless it's a public accessible API, then you probably don't care).
You could use
RMI. This would allow you to expose server objects that the client could interact with. This is good if you wish to send objects from the server to the client. It allows the client to interact with Java objects as if they were local objects.
From a coding point of view, this is a (relatively) simple solution, as you are dealing with Java Objects. The problem is though, only Java clients (with the right libraries) will be able to access the server.
You could use
Plain Sockets. This will allow you to connect to a service on the server and communicate with it.
You can even serialize objects between the client and server, allow the application to deal with Java Objects as well.
This is also a much more difficult approach, as you become responsible for dealing with the low level protocol and error handling (which RMI takes care of for you).
This approach does, however, provide you with the opportunity for other clients to connect to your server (so long as you are using just a plain sockets and serializing objects ;)).
This is a lot of work...
You could use
Some kind of web service (Servlet's under Tomcat for example or event a J2EE server), that would use simple HTTP requests to list of available services/functions that would return either something like JSON or XML response which the client would then need to parse.
This is, by far, the most open and probably the most common solution. It would take some work to get running, but is far less involved then using something like sockets and is also the most flexible, as you wouldn't need release no libraries each time you want to change or update a service.
Now all these allow you to provide secure connections over the wire, through SSL, you just need to establish the correct connection from the client to the server, so you've got an added level of security.
Each hides the database access behind a server layer, adding additional protection to the database.
I'm writing a client-server program in java.
The basis is that the program presents eulas and options to the user and the user responds accordingly, moving through menus until he can get the server to provide the client with the requested item. For example, a document or file.
My question is where should I handle the state of each individual client. Should each client maintain it's own state, should the server create threads to maintain the state of each of it's client, or is there an even better approach?
What would be the simplest and/or most efficient method of approaching this problem?
I would assign each client an ID (for instance, a session ID) and track the state on the server. This would make it harder, I think, to game the system (under the principle that the less sensitive info there is on the client side, the better.)
What kind of client/server protocol are you using? If you're using HTTP, you could use the built-in session capability provided by Java Servlets (assuming you're using those, too.)
Here's a tutorial:
http://docs.oracle.com/javaee/6/tutorial/doc/bnagm.html
Scenario: User logs in on the client software which forms a persistent bidirectional connection with the serverside entity (server) which would process user specified tasks. When the serverside entity, while processing user's task, encounters an error or requires further user input, it will notify the client software, and wait until the client decides what to do. The client software will take the new user specifiefd inputs and send this to the serverside. The serverside continue where it last stopped with the new user specified inputs. This feedback cycle will continue until it's finished processing. The progressively updated user inputs will all be stored on the serverside and accessible and modifiable from the client software. So if a client deletes a specific input, that change will be immediately reflected on the serverside. On the serverside, an extra interface is probably required to route different user's clients to available hardware nodes (cloud) to support concurrent multi-user tasks running on the serverside.
On the client side, I suspect using sockets to connect to the server...
Now for the server, I am a little lost because there seems to be many different Java servers like Jetty & Netty. I am also practicing caution in order to not try and reinvent any wheels here.
Is building a server the right approach? or Build a webservice that will complete a specific task on demand?
I am also not just looking for a one size fits all solution (wishful thinking probably) but open to any insights on my current situation.
Netty will provide a lot of what it sounds like you need for this, without making you reinvent a socket server. That said, I would make certain that you actually need bidirectional, real-time communication between the client and server. If you can rework the problem such that the client-server communications do not need to be real-time, then things like RESTful webservices become a possibility, and (in my experience) are much less complicated and error prone.