AJAX and Client-Server Architecture with JavaScript

前端 未结 5 538
误落风尘
误落风尘 2021-02-03 13:00

I have to program websites, but I rather don\'t like the static HTML nature. I prefer more of a client-server architecture.

Now I\'ve figured, that with XMLhttp, you can

5条回答
  •  攒了一身酷
    2021-02-03 14:01

    There are several different ways to accomplish this. Some of them are already answered here, but I wanted to include a few more as well as my thoughts on them.

    1. Polling

    Frequent requests are made to the server to check for new info. This is the worst way to do this, but probably the easiest. If your site will have a low number of users, it might be worth doing it this way.

    This can be accomplished by using setInterval(myFunction, n) in javascript to send XMLHttpRequests to the server every n milliseconds. Then, on the server, you respond to this with your new info, when you have it, or some message that implies no new info.

    2. Long Polling

    When the page is loaded, it makes a request to the server for new info. The server holds the connection open until there is something to send back. This method reduces the amount of network traffic used, but increases the resources used on the server. You can use this for a small number of users, but it doesn't scale very well.

    The easiest way to do this is to have the page that handles the AJAX request simply wait for new information to be available, then respond. This can tie up a lot connections on your server. So, use with care.

    3. COMET

    COMET is basically long polling, but the server is setup properly for it. It knows that these connections aren't "real" and it uses less resources to handle them. This is a great solution for this problem, but it requires that the server is explicitly setup for this purpose. There are COMET servers and COMET addins for other popular servers, but it will require some setup and sometimes some money.

    Implementing this on .NET isn't the easiest thing in the world. You can pay for solutions, try to find someone else's code that does something similar, or try to write it yourself. I've not found any decent free solutions for this. If someone else has, please comment.

    4. RIA

    Another solution would be to include Flash, Silverlight, or Java Applet on your page. People often do this by using a 1x1 object so that they can use Flash or Silverlight to talk to the server. If you don't mind adding the dependency, this is a decent solution. If you already know Silverlight or Flash, it could be relatively simple to implement.

    You can find tutorials on the internet for each of these options.

    5. Web Sockets

    If you are on the cutting edge, you can look into Web Sockets. It's only available in the latest builds of modern browsers. It was part of HTML5, but it might be its own spec now. Regardless, it means that older browsers won't be able to handle it. But, if you don't mind limiting yourself to the latest of browsers, you can use this amazing feature.

    I believe that Chromium is the only browser that currently supports it. However, there is work being done to implement this in Firefox and WebKit.

    I'll spare you the controversy and simply say that this does exactly what you want it to. The Abstract of the spec says it all.

    This specification defines an API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.

    Special Mention

    If you are interested in the world of Node JS, you can't go wrong with Socket IO. It will implement the best of whichever technology is available to the browser.

    Conclusion

    The best option is Socket.IO on Node JS. However, for an ASP.Net solution, go for COMET or Web Sockets, if you can. Otherwise, using Flash/Silverlight isn't terrible. Finally, polling and long polling should be last resorts. You could always support one of these, then fall back to another if there isn't support for it in the client's browser.

提交回复
热议问题