I have a design question. I have a website where users enter short messages and they are displayed to other users. Sometimes these messages have formatting in them so I need to manipulate strings. I can do this either on the server or on the client. My question is where should it occur?
If it happens on the server then there's more of a load on the server as well as more data to push to the client. However, the server machine will usually be a "better" machine than what the users have.
If it happens on the client the string manipulation gets offset to the users but I'm not sure how efficient javascript/jquery string manipulation is.
Any thoughts on this?
I can't imagine a "short message" that would take so much string manipulation that a client machine would be noticeably inferior to a server. Put it on the client.
Well I am not sure how you are getting this string to the other users but I am assuming you sending it back to your server anyways so the question is, should you get it clean on the client and then send it to the server or just take whatever you get and clean it on the server.
If you can guarantee javascript is enabled then offloading it to the client would really cut down a lot of extra mini processes on the server with each call and distribute that load to the client which is great.
Things to consider... if you do it just in javascript you have no guarantee of what you are getting since you are not checking / cleaning the string on the server. This could be dangerous depending on how you are sending this information to other users. Just think of javascript injection attacks.
If you do it on the server then you don't really have to worry about it because you can guarantee what you are sending out is exactly what you want instead of just passing through whatever and hoping the javascript on the client has you covered.
Are you really doing so many transactions that the string manipulation is that much of a factor compared to whatever other operations you are doing with each message server side?
Depending on your definition of short (>1024 characters works for me) you would have to be turning through a LOT of them for there to be significant to your server.
That said...the fewer round trips you can make from your client to the server the better. Try to do it in JavaScript first. Then move it to the server if you have to.
I'd be tempted to keep it on the client side as much as possible. I might even go ahead and have client-side code compact / extract the messages as they arrive to save my web service or whatever is handing off the messages some bandwidth.
Related
Is it possible to make a multiplayer rpg game without a server?
I thought about authentication, and that seems sort of fine in p2p.
But, how to store the savefile so that no one has reason to / can change it?
I thought about letting the user to store savefile of their character locally ... but I can't think of a way to prevent people to change savefile of their character.
If this is really not possible without a server, how to minimize communication with the server?
I thought about making a save point, but that is not fair. Because the user can choose not to save when something bad happens to them.
Unless the design of the game is that the worst that can happen is they don't get something (same as deliberately not saving). Then this can work.
Thanks for your help.
You could design your savefile similar to a git-repo. Don't override everything but instead save the whole history. Since you are planing a plausibility check anyway, the single 'commits' could be signed by all participating clients.
When a client joins the network, all other clients get the savefile and judge its validity based on the signatures and maybe some deeper plausibility checks. If they have a doubt, they would refuse the user to join.
There are some disadvantages:
The management of the trust relations. If I have a few clients under control, I could still forge a savefile with valid signatures.
The savefile can grow large. However, you'll only need it when joining, afterwards the last state is sufficient to hold in memory. One could also have some server-signed 'commits' in the chain, then you only have to submit the chain back to this commit.
It is quite easy to update the interface by sending jQuery ajax request and updating with new content. But I need something more specific.
I want to send the response to client without their having requested it and update the content when they have found something new on the server. No need to send an ajax request every time. When the server has new data it sends a response to every client.
Is there any way to do this using HTTP or some specific functionality inside the browser?
Websockets, Comet, HTTP long polling.
It has name server push (you can also find it under name Comet technology). Do search using these keywords and you will find bunch examples, tools and so on. No special protocol is required for that.
Aaah! You are trying to break the principles of the web :) You see if the web was pure MVC (model-view-controller) the 'server' could actually send messages to the client(s) and ask them to update. The issue is that the server could be load balanced and the same request could be sent to different servers. Now if you were to send a message back to the client you'll have to know who all are connected to the server. Let's say the site is quite popular and you have about 100,000 people connecting to it every day. You'll actually have to store the IPs of each of them to know where on the internet they are located and to be able to "push" them a message.
Caveats:
What if they are no longer browsing your website? You see currently there is no way to log out automatically if you close your browser. The server needs to check after a fixed timeout if you have logged out (or you send a new nonce with every response to prevent the server from doing that check)
What about a system restart/crash etc? You'd lose all the IPs that you were keeping track of and you are back to square one - you have people connected to you but until you receive new requests you can't really "send" them data when they may be expecting it as per your model.
Let's take an example of facebook's news feeds or "Most recent" link close to the top right - sometimes while you are browsing your wall you see the number next to most recent has gone up or a new 'feed' has come to the top of your wall post! It's the client sending periodic requests to the server to find out what was updated rather than the other way round
You see, it keeps it simple and restful. You may feel it's inefficient for the client to "poll" the server to pull the data and you'd prefer push, but the design of the server gets simplified :)
I suggest ajax-pulling is the best way to go - you are distributing computation to the client and keeping it simple (KIS principle :)
Of course you can get around it, the question is, is it worth it?
Hope this helps :)
RFC 6202 might be a good read.
I have to create a Java EE application which converts large documents into different formats. Each conversion takes between 10 seconds and 2 minutes.
The SOAP requests will be made from a client application which I also have to create.
What's the best way to handle these long running requests? Clearly the process takes to much time to run without any feedback to the user.
I can think of the following ways to provide some kind of feedback, but I'm not sure if there isn't a better way, perhaps something standardized.
The client performs the request from a thread and the server sends the document in the response, which can take a few minutes. Until then the client shows a "Please wait" message, progress spinner, etc. (This seems to be simple to implement.)
The client sends a "Start conversion" command. The server returns some kind of job ID which the client can use to frequently poll for a status update or the final document. (This seems to be user friendly, because I can display a progress, but also requires the server to be stateful.)
The client sends a "Start conversion" command. The server somehow notifies the client when it is done. (Here I don't even know how to do this)
Are there other approaches? Which one is the best in terms of performance, stability, fault tolerance, user-friendliness, etc.?
Thank you for your answers.
Since this almost all done server-side, there isn't much a client can do besides poll the server somehow for updates on the status.
#1 is OK, but users get impatient really fast. "A few minutes" is a bit too long for most people. You'd need HTTP Streaming to implement #3, but I think that's overkill.
I would just go with #2.
For 3 the server should return a unique ID back to the client and using that ID the client has to ask the server the result at a later time
option 4 for those desiring to use web sockets
you request will be response with a jobId,
you get progress state over the web soket
This may be a dumb question - and the title may need to be improved... I think my requirement is pretty simple: I want to send a request for data from a client to a server program, and the server (not the client) should respond with something like "Received your request - working on it". The client then does other work. Then when the server has obtained the data, it should send an asynchronous message (a popup?) saying "I've got your data; click on ... (presumably a URL) to obtain data". I have been assuming that the server could be written in Java and that client is html and JavaScript. I haven't been able to come up with a clean solution - help would be appreciated.
Try to employ "Websocket Method" by using "SuperWebSocket" for server side, and "WebSocket4Net" for client side. It is working perfectly for my current project.
Most of the work invovles the server being asynchronous. To do this you must
Have an ajax call to the server that starts a job and returns a confirmation the job has been started.
A page on the server that will return whether or not any jobs are complete for a user.
Have an ajax widget on your client side that pings that page on teh server every so often to see if any jobs have been completed. And if so make a pop up.
This is the only way unless you use Flex data services.
Are you trying to do this on the HTTP protocol? It sounds like you're talking about a web application here, but it's not clear from the question. If so, then there are a variety of techniques for accomplishing this using AJAX which collectively go under the name "Comet". Depending on exactly what you're trying to accomplish, a number of different implementation, on both the client and server side, may be appropriate.
for pure java i suggest something like jgroups (client+server are java)
for html, you should use ajax - there you have a timer that checks every X seconds
Nowadays you have an alternative technique to use: Websockets. These are used for server->client communication without polling or ajax-style delayed responses.
We currently have fairly robust error handling functionality in our ASP.Net application.
We log all errors in the database, a text file on the server
and also send automated emails containing the error details back to our support people.
This all happens on the server of course.
We would like to capture (and retrieve) an image of the client browser at the time the error occurred to provide additional info for troubleshooting?
Is this at all possible?
If so what would be an elegant approach to this problem?
This is not technically impossible, but it is so impractical for nearly all purposes that it might as well be impossible. You would need a plugin running on the client's machine which can receive instructions from your error page to take the screenshot, connect to the server and upload it.
If your client screens have complex data which affects the state surrounding the exception, you should revisit your design to ensure all of that is recorded before it's sent to the client, so you can keep all relevant state tracked with a given exception.
Saying something is "impractical" is usually easier than actually trying to solve something that is difficult, but not technically impossible.
I have done some more research and have come across
an approach that allows one to get hold of the rendered html server side.
Further more, there are ways to also convert html to images
I will implement the solution using a combination of the two.
Capturing a client browser screenshot is not possible due to security and privacy reasons. What you can (and imho you should) do is capture the url and the browser version and try to reproduce it in the same environment.