本人参与一个物联网项目，从底层PLC到服务器，再到客户PC，进行实时监控。希望客户端尽可能实现跨平台，就考虑B/S架构实现，但B/S架构有一个十分明显的缺陷，就是无法建立长连接实现实时的数据显示，大家有什么较好的思路或者解决方案，相互分析和探讨。
有研究和考虑在客户端使用HTML5实现，但现在HTML5普及度是一个问题。
如有描述不周，还请见谅，望有利于今后物联网的工程实现。
————————————————————————————————
现在考虑HTML5实现，有清楚HTML5的优缺点的么？
————————————————————————————————
统一了下大家的回答和我们现行的方案：
Web前端用HTML5实现websocket，低版本浏览器使用flash或 Socket.IO进行websocket通信.
服务器端也实现websocket。
————————————————————————————————
重新看了标题，想解释为什么是B/S架构的客户端Socket编程？
B/S结构最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。跨平台必然是以后客户端开发的重要因素。
物联网系统发展趋势，是将B/S与C/S的优势完美地结合起来，就是说，物联网的应用系统既能以B/S的方式发布运行，同时又具有C/S方式的极强的可操作性。
以后物联网是大数据时代，客户端承载数据的显示，而数据的分析必然要放到后台服务器，所以Web Broswer是目前就为不错的方式，但物联网还有实时性控制和数据展示的问题，比如调用远端的摄像头，家里的火警报警器等，这就是目前HTTP协议不能做到的，因此需要Socket方式来保证实时性。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
对物联网斗胆发表个人愚见，望抱砖引玉，如有错误，还望大家见谅指正。
但是实际上，HTTP 1.1 默认是启用了 Keep-Alive 特性的，允许连接复用，也就是说，如果你用的浏览器不是太古老，那么这样的轮询程序实际上比你想象的还要高效——因为只有你第一次发送请求时才会为你建立连接，之后你继续发送请求都会优先使用这同一个连接。所以“长连接”实际上早就被实现了。而且甚至没有被程序员意识到。
你遇到的问题并不是“长连接”问题，而是数据的“推/拉”问题。也就是说，你真正想要的，是服务端能够主动的将数据源源不断的发送给客户端——而这一点恰好是 HTTP 协议的软肋。这也是为什么会有 websocket 的一个重要原因。
一种方法是使用 http://socket.io 之类的库。还有一种容易被忽视的方案是使用一种改进的轮询方案：comet 。
当然我不知道你需要实时显示的数据的单位时间内的流量，对延迟的容忍性，所以其他方面也给不了建议了。其实可以采用flash外挂结合支持websocket的浏览器实现,
1,flash是可以开启socket链接的，在页面嵌入一个不可见的flash,接收消息逻辑封装在此，然后使用javascript和flash进行消息之间的交互
2,如果浏览器支持websocket则优先采用websocket,消息接口可以定义好，具体2种实现。websocket
要兼容老浏览器可以考虑 http://socket.io 之类的方案。看一下这张图
![物联网的实时性问题 B/S架构的客户端Socket编程？-LMLPHP]( "物联网的实时性问题 B/S架构的客户端Socket编程？-LMLPHP")
http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comethttp://socket.io。
至于兼容性的问题，都要做物联网比较前沿的东西了还不推动技术进步么。1. 轮询方式 参看 @林建入 的答案
2. 伪长连接方式，也叫长轮询模式 客户端链接到服务器后，服务器一直不要断开，用trunk方式，有数据就输出，类似页面一直未加载完的状态。客户端如果发现链接被网关断开，则重新连接。服务器也可以实现推送机制。早期的网页聊天室基本是这种方式实现的。
补充： 早期网页版本用的是iframe方式的长轮询，而新的都用的是Ajax方式请求。看了一下微信的网页版聊天，也用的是这种模式。这种模式的浏览器兼容性是最好的。
3. websocket
4. 浏览器插件
补充: 具体参看
Comet (programming)
有研究和考虑在客户端使用HTML5实现，但现在HTML5普及度是一个问题。
如有描述不周，还请见谅，望有利于今后物联网的工程实现。
————————————————————————————————
现在考虑HTML5实现，有清楚HTML5的优缺点的么？
————————————————————————————————
统一了下大家的回答和我们现行的方案：
Web前端用HTML5实现websocket，低版本浏览器使用flash或 Socket.IO进行websocket通信.
服务器端也实现websocket。
————————————————————————————————
重新看了标题，想解释为什么是B/S架构的客户端Socket编程？
B/S结构最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。跨平台必然是以后客户端开发的重要因素。
物联网系统发展趋势，是将B/S与C/S的优势完美地结合起来，就是说，物联网的应用系统既能以B/S的方式发布运行，同时又具有C/S方式的极强的可操作性。
以后物联网是大数据时代，客户端承载数据的显示，而数据的分析必然要放到后台服务器，所以Web Broswer是目前就为不错的方式，但物联网还有实时性控制和数据展示的问题，比如调用远端的摄像头，家里的火警报警器等，这就是目前HTTP协议不能做到的，因此需要Socket方式来保证实时性。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
对物联网斗胆发表个人愚见，望抱砖引玉，如有错误，还望大家见谅指正。
回复内容：
假设你写一个 Javascript 小程序，每隔 1s 就发送一次 HTTP 请求到同一个 URL 获取一次数据，那么你可能很自然的会想这会导致不断的重复建立连接做收发，不太好。但是实际上，HTTP 1.1 默认是启用了 Keep-Alive 特性的，允许连接复用，也就是说，如果你用的浏览器不是太古老，那么这样的轮询程序实际上比你想象的还要高效——因为只有你第一次发送请求时才会为你建立连接，之后你继续发送请求都会优先使用这同一个连接。所以“长连接”实际上早就被实现了。而且甚至没有被程序员意识到。
你遇到的问题并不是“长连接”问题，而是数据的“推/拉”问题。也就是说，你真正想要的，是服务端能够主动的将数据源源不断的发送给客户端——而这一点恰好是 HTTP 协议的软肋。这也是为什么会有 websocket 的一个重要原因。
一种方法是使用 http://socket.io 之类的库。还有一种容易被忽视的方案是使用一种改进的轮询方案：comet 。
当然我不知道你需要实时显示的数据的单位时间内的流量，对延迟的容忍性，所以其他方面也给不了建议了。其实可以采用flash外挂结合支持websocket的浏览器实现,
1,flash是可以开启socket链接的，在页面嵌入一个不可见的flash,接收消息逻辑封装在此，然后使用javascript和flash进行消息之间的交互
2,如果浏览器支持websocket则优先采用websocket,消息接口可以定义好，具体2种实现。websocket
要兼容老浏览器可以考虑 http://socket.io 之类的方案。看一下这张图
http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comethttp://socket.io。
至于兼容性的问题，都要做物联网比较前沿的东西了还不推动技术进步么。1. 轮询方式 参看 @林建入 的答案
2. 伪长连接方式，也叫长轮询模式 客户端链接到服务器后，服务器一直不要断开，用trunk方式，有数据就输出，类似页面一直未加载完的状态。客户端如果发现链接被网关断开，则重新连接。服务器也可以实现推送机制。早期的网页聊天室基本是这种方式实现的。
补充： 早期网页版本用的是iframe方式的长轮询，而新的都用的是Ajax方式请求。看了一下微信的网页版聊天，也用的是这种模式。这种模式的浏览器兼容性是最好的。
3. websocket
4. 浏览器插件
补充: 具体参看
Comet (programming)