I have develop a silverlight 3 chat application in which one user chat with multiple users on a same time.
In my application a chat window is a
silverlight control and a user can
open more than 10 chat windows on same
time in a single browse window.means
every chat window make connection with
wcf.
I have allready increase connection limits of wcf using throttlingservice behavior. It works for multile clinets means multiple browses open on same time on different machines and its more than 10. its ok. but if when one user chat with more than 10 users on same time then on 11th connection its break.
please help me and provide me solution for this problem.
Thanks
I think there is something wrong with your client implementation. Do your clients keep the connection to your server open for too long? Ideally you should only have very compact and short request/reply messages between the client and server such that each connection is only short-lived.
A user cannot send messages from each client simultaneously, I suspect. So you should hardly ever have to open more than one connection between client and server simultaneously.
Do you get the exception if all the other channels are closed? There may be a limit to the number of active connections. You may have to dole out connections between windows when there are more than ten open windows to ensure that you don't attempt to open that 11th connection.
Related
I'm trying to build a simple chat with websockets. I'm also displaying the current active users in the chat, and here is where the problems start: we use a web farm.
A user can connect through a loadbalancer with a server. When a new connection hits a server, it increases a counter in a SQL database and notifies the other servers in the farm through rabbit MQ.
All other servers fetch the new data and send that number back to their connected users.
If an user disconnects, the same will happen: The server decreases the counter in the SQL database and through rabbit MQ all other servers will know about this.
But, what will happen when a server dies? for example, If 10 users will be connected with this server. When that server goes down, all the users are disconnected, but that is not updated in the database anymore.
What's the best solution to get the total amount of active users in a web farm? And notifying the users when this amount has changed?
Thanks in advance!
Oh btw, we're using signalr
I think the typical way to deal with nodes asynchronously disconnecting from a mesh is to implement a heartbeat/keep-alive mechanism. In this case the heartbeat message would be between servers and there must also be an accessible record of which users are connected to which server. When a server does not produce a heartbeat for a period of time, then all other servers can update their records and mark all the users associated with the server as disconnected.
Looks like you may have a few options on how to keep track of users (SQL database or every server listens a Rabbit MQ message). As far as the heartbeat, you can implement it yourself or try to see if the laodbalancer's detection method can be utilized.
I have always followed the guidance of try/Close/catch/Abort when it comes to a WCF proxy. I am facing a code base now that creates proxies in MVC controllers and just lets them go out of scope. I'm arguing the case that we need to edit the code base to use try/Close/catch/Abort but there is resistance.
Does anyone know a metric (e.g. perfmon) I can capture to illustrate the problem/benefit. Or a definitive reference that spells out the problem/benefit no one can dispute?
You can create a sample application to mimic the problem. Though I haven't tried you can try this,
Create a simple service and limit the maxConcurrentCalls and maxConcurrentSessions to 5.
Create a client application and in that, call the service method without closing the connection.
Fire up 6 or more clients
See what happens when you open a new connection from a client. Probably the client will wait for certain time and you get some exception.
If the client don't close the connection properly, the connection will still remain open in the service so what happens if 1000s of client connected to the service at a time and leave their connections open? The service has a limitation that it could server 'n' connections at a time and because of that the service can't handle any new requests from clients and that's why closing connections are very important.
I think you are aware about the using problem in WCF service. In my applications I close the WCF connections using an extension method as said in this thread.
Have you tried a simple 'netstat -N' from the command prompt both on server and client? Yoy are likely to see a lot of waiting/pending connections which might exhaust your server resources for no reason.
I'm working on a messaging app (something like WhatsApp) and I have a dilemma about implementing it's main functionality - sending message from client1 to client2.
The thing is I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients, so clients have a timer and query the server every 2 seconds to see if a new message is waiting for them.
The problem with this approach is that querying the server every 2 second seem to kill the battery very fast, so I thought maybe instead of client querying the server, to use APNS so when client1 send a message to the server, the server will send a push notification to client2, then client2 will fetch the data from the server.
Will this approach work with a massive messaging app requiring massive push notification uses?
Yes. I would say this approach is okay and will perform well.
You could also create a socket connection when your application is running in front. But the APNS-way (your preferred way) will also work when the user has quit your app.
APNS can handle huge load. There where only very few delays as far as i noticed.
The PUSH-System on iOS is just a HTTP Connection to apple which keeps the response-channel open for some hours (like loading a webpage for some hours).
It will use around +10% of your battery.
So best would be to not create another keep-alive HTTP/Socket connection and to re-use apples channel (APNS) to save the endusers battery.
In your app you will receive the Push-Notification and you can parse the JSON-Data and then pull/sync with your own server.
You should also take in mind what to do, when your app is not running in foreground (then you might display the received message as APNS messages as WhatsApp does).
Why can't the application server send messages directly to the application? Why do you need the C2DM service in the middle?
To send a message from the server side you have two possibilities:
The client polls for new messages in certain intervals. Downside: Not a real-time solution. If you poll too frequently it will drain battery, consume your quota (if you don't have an unlimited package). Generally you do a lot of unnecessary work and traffic as most polls will return no messages.
Stay connected all the time. Downside: hard to deliver technically as phones can close connections when going to sleep mode. (At least nothing guarantees that they won't). Also you are running a background application 24/7.
The current state of C2DM will give you:
The ability to get messages even when your application is not running as Android will start your application (the part of it you configured, not necessarily the whole UI) when a message arrives.
A central, shared channel to deliver such messages. If 10 applications need real-time notifications on your phone this is one single facility, not 10 applications running and polling in parallel.
The promise: As this is the sanctioned API by Google for push messaging you can expect it to be optimized in the future. One improvement can be carrier-level messaging to initiate a C2DM session. That would mean you can put 100% of the "smart" part of your phone asleep.
Because the application can't (or isn't supposed to) act as a server.
If you would like to send messages to your app directly, then your application would need to have some sort of server listening in some port. This is bad because:
connections are usually firewalled, you cant just listen in some port,
your device can be turned off or without connectivity (then you app sever would need to retry),
the app server would need to know the address of your device,
app would need to be running (at least the server module) all the time, this isn't battery friendly.
I have a windows forms application. I need to send data to it whenever something happens on the server.
How should I implement this?
You need notification from the server of the event, so I would open a persistent TCP connection to the server and listen for the notification. This means you'll have to write the server for it to connect to.
Alternatively, you could connect only periodically and check for notifications. You would put the connection on a Timer control and set the interval in the config, or maybe even user settings.
If you're in the MS world, this is what WCF is for...it makes it pretty easy, though WCF configuration is a black art in and of itself.