I am having a server where my java
web application and database
server reside.
Now the clients of my web app are
of two types:
ClientType1
ClientType2
Both can access the database.
ClientType1 stores the data in the database.
ClientType2 retrieves the data from the database.
But the ClientType1 should start
storing the data in the database
when the ClientType2 says
Start.
Similarily ClientType1 should stop storing the data in the database
when the ClientType2 says Stop
===========================================================================
Q1. What are the solutions for this problem?
Here are the approaches I thought of:
Create a table in the database having one column that shows the status Start or Stop and this column's value should be set by ClientType2. ClientType1 will keep sending the query to the database for getting the status from this table and perform operations according to the status.
Apply ServerPush approach by which the server will keep a connection with the ClientType1 alive and will send the request to him whenever it receives the command (Start or Stop) from the ClientType2. Problem with this approach is that the no. of open sockets at the sever will increase as the increase in the no. of ClientType1
You should use a kind of Ajax for this since this abstracts the "server can call client" away.
Choose a library that allows you to keep a single connection open and do multiple things through this connection.
I don't really consider interprocess communication through a database to be a great approach. The typical scenario is that the client registers itself with the server making it eligible for receiving messages using a socket-based mechanism.
The client can then either:
Ask the server to perform a database operation on behalf of it
Request access to the database
If there are that many clients that keeping an open connection will be a problem you could either initiate a new connection every time you need to communicate with the server or let the server offer e.g., some kind of REST API which the server can poll.
Related
I would like to know the architecture of real time chat for millions of users like whatsapp.
I implemented a chat but I need to use more servers to handle more clients
I read another question, but I still have doubts about.
Tell me if what I say is correct:
Clients connect to load balancer that decide to give connection to one of the whatsapp servers.
Example ClientA connect to Server1,
ClientB connect to Server2,
-If ClientA wants to communicate with ClientB, sends a message to the Server1 ,now, this how do you know in which server is ClientB ? Maintaining the scalability to millions of users )
How to implement a chat to handle millions of users?
The key is the database (or any other persistence system) where all the input from the clients gets stored. Usually in these scales, a key-value NoSql Database is suitable, like Apache Cassandra, Amazon Dynamo, or Google Datastore.
These databases are optimal for fast insert and fetch by PK only.
All the servers need to be stateless, so Client A connects to Server A and sends a text message and destination client Id. This gets stored in the DB. Then, client B connets to Server B which goes to the database and retrieves the text.
I have a working xmpp web client using strophe,my current approach is to login user from strophe on java script,but security point of view it is not secure and in my application ihave to switch pages vary rapidly,
while searching on internet on SO i found that Jake Moffitt has given a solution of implementing session which overcome both limitation ,as mention in his book "professional xmpp using java script",one can easy implement session and get SID and RID on server[have to create xmpp bosh connection from server]and pass it to java script(jid,sid and rid) which will than used in attach() method to connect with xmpp bosh manager,
I am using java as server side language,while some one try to implement boshclient in java it seem java smack and jbosh is only available solution (i mean working solution),
But i couldn't find any method by which i can get RID and SID using java script, i went through another approach
why not run strophe client on top of jvm,(why to run strophe on jvm? i am able to get rid and sid using strophe on java script as mention on this link ,why one should try this solution on java) i have included rihno in my dynamic web project js.jar to my lib folder in WebContent/WEBINF/lib and gave a qualified path to run env.rihno.js which create an browser run time on java and included strophe.js and jquey.js file and try to connect to bosh clint as i did on javascript for my web app,
code::
Context cx = ContextFactory.getGlobal().enterContext();
cx.setOptimizationLevel(-1);
cx.setLanguageVersion(Context.VERSION_1_5);
Global global = Main.getGlobal();
global.init(cx);
Main.processSource(cx, "/home/devwrat/workspace/Test/env.rhino.1.2.js");
Main.processSource(cx, "/home/devwrat/workspace/Test/jquery-1.11.1.js");
Main.processSource(cx, "/home/devwrat/workspace/Test/strophe.js");
Main.processSource(cx, "/home/devwrat/workspace/Test/boshconnection.js");
It seem everything is working fine on java until cinnection.connect() using strophe execute in my java script,i observers that it is not connection to bosh manager.
My question is as below
is it possible to establish bosh connection using strophe in java? and yes how?
thanks in advance!!!!
Edit (21-8-2014)::
I observed that after executing conn.connect(Arthur.jid, Arthur.password, function (status){print(status);}),status is 1 which in turn means connection status is connecting,it always say connecting never get connected ??May be xmpp bosh manager is not authenticating connection!!!
Strophe.js is usually used with the client side javascript. I think you're adding unnecessary complexity by trying to run Strophe.js on the server side.
You've mentioned two separate problems, moving authentication to the server side, and also maintaining session between page changes.
Problem #1 Moving authentication to server-side (Prebinding)
If you want to move the login process to the server side, then you can do so by utilizing a java based XMPP library or by manually creating and sending the stanza's (isn't that hard, it's basically just XML being sent over HTTP) which are needed for the authentication process. Once the BOSH session has been established server side, the JID+RID+SID attributes of the session can be passed to the client side javascript and used by Strophe's attach().
In order to write your own BOSH pre-binder, you should start by inspecting the stanza's which are exchanged between Strophe and ejabberd, and you should also read XEP-206. In summary, you will need to create a HTTPClient of some sort, point it towards ejabberd's /http-bind/ address, and begin sending it the same messages that strophe sends during login. You can always inspect the messages (stanzas) with your browser's network debugger, or Fiddler2 (I recommend this). Once you understand how Strophe establishes a session, you can begin writing your own server side mechanism to establish a session. Once the session has been established server side, you can extract the SID+RID+JID, and send them to your page and use them with attach().
Problem #2 Maintaining session between page changes
The second problem you state is that your application changes pages frequently. If you want to implement a mechanism to maintain your XMPP session between page changes, this can be done by utilizing strophes attach() in combination with a mechanism to store the JID+RID+SID. I use a combination of LocalStorage with fallback to AJAX to accomplish this.
BOSH and XMPP
The reason you cannot extract the RID and SID values from many XMPP libraries is because they don't use these attributes. SID and RID are used with BOSH, which is what enables us to communicate with an XMPP server using HTTP. With a web application using BOSH to communicate to an XMPP server, we have 3 levels: the XMPP server itself, a BOSH connection manager, and the web application. Since HTTP is stateless, and XMPP is not (it's designed to maintain a persistent connection), we need to use a BOSH connection manager to maintain that persistent connection to the XMPP server. This connection manager is what's managing our session with the server and handling the intermittent requests from the web application, it's able to push messages to the client with Comet.
In order for the BOSH connection manager to validate the intermittent requests coming from the web application, we include a SID and a RID attribute with each stanza. The SID will remain the same during the lifetime of the session, and the RID will increment by 1 with each outgoing request. It is important that the RID is incremented properly, if a request with an unexpected RID is sent to the connection manager, the session is usually ended and the connection manager will return an error.
Hope that helps.
I have seen a lot of tutorials on client/server chat rooms using sockets, I am trying to create a instant messenger which will allow users (stored in a sql db) to chat with there contacts and groups(also stored on sql db). now I am really puzzled where to start. how would i go about creating a server which can handle peer to peer chat and group chat. I am using a mysql database which will store the user data and contacts list.
To get you started on ServerSocket and ClientSockets for multiple clients you can refer to the below post.
Two Socket sharing a port
Ideally every client would have only 1 socket connection to the server. To differentiate between your chats you can very simply use a unique identifier which will help differentiate between the different chat types.
You will need to create a multi-threaded socket server, this will accept incoming connections on a loop, and then pass off all operation between that instance of the socket and the client into a separate thread. This will allow you to run multiple client connections at once. This Page goes into great detail about creating both single and multi-threaded chat servers.
I am looking to build an instant messenger in Java.
Clients will connect to the server to log in.
They will start a conversation with one or more other clients.
They will then post messages to the server that will relay the messages to all the clients.
The client needs to be continually updated when users post messages or log in.
so the way I see it, the client needs to run a server itself in a separate thread so that the main server can send stuff to it. Otherwise the client will have to the poll the main server every xyz seconds to get the latest updates. And that would need a separate thread anayway, as that would be purely for getting updates whereas the 'main' thread would be used for when the client initiates actions such as posting messages/inviting others to conversations etc...
So anyone recommendations on how to write this instant messenger? Does it sound like a good idea to make the connection a 'two-way' connection where both the client and server act as servers? Or is polling a better option? Anyone know how the IRC protocol does this?
There's no real advantage of having 2 connections unless they can be handled independently (for example receiving / sending a file usually done in a separate connection). A connection itself is already a two-way communication channel so it can be used to both send and receive messages, events etc. You don't need to poll server since client is able to maintain persistent connection and just wait for data to appear (optionally sending periodic PING-like message to ensure connection is alive).
IRC uses a single connection to server to exchange text commands. For example one of the main commands:
PRIVMSG <msgtarget> <message>
This command can be originated either by client or by server. Client sends PRIVMSG to notify that it wants to deliver message to one or more destination (in IRC this either user(s) or channel(s)). Server's task here is to properly broadcast this message to appropriate clients.
If you're using raw InputOutput streams then yes this is a good way of doing it. You create one thread on the clientside that acts in a similar fashion as the server thread - waits for any incoming updates and when it does it updates the client. I wouldn't call it a server though. So you'd ideally have 2 TCP/UDP connections one for requests made by the client and one to notify the client of server changes.
This solution in an enterprise environment would probably be done through some kind of messaging framework such as Spring Integration but dig deep enough and it will essentially be a similar way to how you mentioned.
Do you need a fully custom protocol or would it be sufficient to use the XMPP? There are several open source libraries implementing XMPP.
http://xmpp.org/xmpp-software/libraries/
e.g. http://www.igniterealtime.org/projects/smack/
For me, to develop instant messaging service, I will use websocket protocol instead of normal java socket because the normal socket can not work well with HTTP protocol and moreover some network providers and firewalls banned custom ports. If you develop it in normal socket, your service could not be accessed by web clients.
Did you plan to develop the instant messaging service yourself? How about using other protocols such as Jabber?
Assume a distributed communication system where client and server communicate via a stateless channel.
The client sends requests to the server and the server does processing and keeps internal records for each client.
Server sends back notifications to the clients as various events happen to the system, as needed.
The notification mechanism depends on the internal records.
My question is, what is the standard appoach in distributed computing to handle the client failures?
I.e. in this context, assume that the client process crashes or simply restarts.
The server still has the records for the client but now client and server are of sync.
As a result client will get notifications according to records created before restart. This is undesirable.
What is a standardized way to detect the client failures? E.g. client has restarted and previous records must be erased?
I thought of periodic callbacks to clients and if a client is not reachable, erase its records but I am not sure if this is a good idea. [EDIT] I thought of callbacks because, the period events send back to the client can be in very large intervals and so the client failure would not be noticable soon
Can anyone help on this? The context of my application domain is web services.
Thank you!
The standard approach varies from system to system depending to the architecture and domain. How the server finds out that the client is down? I think you don't need callbacks, since you send the notifications and can detect that the client is unreachable. For example:
send a notification to the client;
if success, goto 1;
else erase all the notifications in the queue for the client, set a flag to not collect events for the client.
When a client is connected:
unset the flag;
start sending notifications
Or even a simpler approach:
erase the notification queue for the client when it connects before initializing the conversation;
run a low-priority thread to erase all the notifications for all the clients which are older then X, to clean notifications for the client which will never come back.
Update after the original author comments
It strongly depends on how things are organized in your system. Assuming:
The server starts a thread (let's call it "agent") to serve a client, a thread per client.
The agent exits when the clients shuts down the session properly or goes down.
there is a private (which is not shared among agents/clients) record set for each client
there is a shared list of current clients which is used by another component (not an ordinary agent, let's call it "dispatcher") to distribute records for clients.
solution:
1. the server starts an agent and registers the client just connected to list of clients. The dispatcher gets notified that a new client arrived.
2. the agent consumes the records until client is connected. On client's shutdown and/or failure the agents unregisters the client and cleans the record set.
If things in your system aren't organized in the way described above, please provide some details.