none
新通知实现服务器端推送,该怎么设计呢 RRS feed

  • 问题

  • 有人在网上发布了通知,则立刻通知相关客户端,客户端程序使用.net 2.0 开发;具体该怎么做呢
    2010年5月27日 1:35

答案

  • 你可以用一个TIMER不断监测数据库中是否有新数据插入,如果有新数据插入,就立刻在客户端显示
    努力+方法=成功
    2010年5月27日 2:08
  • 客户端程序是windows forms

    没有频率这一说,是一有新通知就发给客户端;

    服务器是否要做一个类似web service或什么服务的程序;然后有信息后发给客户端;具体不知该怎么实现


    当有信息的时候 只要知道客户端的IP等信息 直接通过Socket发送就可以了,而客户端直接监听  比如HttpListener TcpListener等
    I see you~http://hi.baidu.com/1987raymondMy Blog~~~
    2010年5月27日 4:52
    版主
  • 服务器端怎么判断是否有信息呢,定时读取数据库么?

    1,通讯协议?

    2,防火墙规则?

    3,通知数据大小?

     

    这些你都不说,对不同的场景有不同的实现方式.版主告诉你的方式,如果是internet,那就不一定适用了,因为有防火墙,有路由器,有动态IP.在这种情况下HttpListener 是肯定不可行的.而TcpListener又受到路由器的inbound限制.

    服务器怎么判断是否有信息,也是根据不同的场景有不同的方式,这得看你是什么样的需求,用不用数据库都还不一定.

    用什么数据库,也还有不同的实现模式.

    2010年5月27日 7:41
  • 通讯协议不限;局域网环境;客户端需要登录;根据用户,服务器将信息推送到客户端;数据量不大,几十个字。


    考虑采用 WCF 写一个发布/订阅服务,使用 TcpBinding,采用 WCF 回调发送通知给客户端.

    更新机制:

    1,发布服务的发布接口中直接调用所有活动的客户端回调;

    2,发布服务将信息写入数据库,然后再读取新信息发送给客户端;

    第一种方式需要额外的服务以支持负载均衡模型,简单的说,你有多个"发布-订阅"服务(Pub-Sub),一个"订阅管理"服务(SubMgr).

    所有客户端向Pub-Sub订阅消息,所有Pub-Sub向 SubMgr 订阅消息;所有客户端发布到Pub-Sub上的新消息都会被发布到SubMgr,SubMgr再将新消息发布到所有订阅该消息的Pub-Sub上,然后各Pub-Sub再将消息发布给各自持有的客户端.

    第二种方式,依赖数据库本身的机制,比如支持Dependency的Sql ,Oracle,这样的话,前面叙述的SubMgr就可以由数据库来担当.在实际使用中,Sql 没 Oracle好使.如果无法实现数据库级别的Dependency的话,则考虑通过Pub-Sub去轮询访问数据库.当然,好的方式是,由SubMgr去轮讯,让后将信息发布给各pub-Sub.

    另外,你还需要考虑持久订阅的问题,客户端未在线的时间内发布的信息是否需要在客户下次登录时发布给客户.如果需要,则需要通过数据库建立持久订阅管理容器,当每次客户登录时,都需要检查客户未接收过的消息,并发送给客户端.

    2010年5月27日 9:11

全部回复

  • 要看你的使用环境而定.

    1,通讯协议?

    2,防火墙规则?

    3,通知数据大小?

    4,通知频率?

    2010年5月27日 1:45
  • 你可以用一个TIMER不断监测数据库中是否有新数据插入,如果有新数据插入,就立刻在客户端显示
    努力+方法=成功
    2010年5月27日 2:08
  • 客户端程序是windows forms

    没有频率这一说,是一有新通知就发给客户端;

    服务器是否要做一个类似web service或什么服务的程序;然后有信息后发给客户端;具体不知该怎么实现

    2010年5月27日 2:36
  • 客户端程序是windows forms

    没有频率这一说,是一有新通知就发给客户端;

    服务器是否要做一个类似web service或什么服务的程序;然后有信息后发给客户端;具体不知该怎么实现


    当有信息的时候 只要知道客户端的IP等信息 直接通过Socket发送就可以了,而客户端直接监听  比如HttpListener TcpListener等
    I see you~http://hi.baidu.com/1987raymondMy Blog~~~
    2010年5月27日 4:52
    版主
  • 服务器端怎么判断是否有信息呢,定时读取数据库么?
    2010年5月27日 6:05
  • 服务器端怎么判断是否有信息呢,定时读取数据库么?

    1,通讯协议?

    2,防火墙规则?

    3,通知数据大小?

     

    这些你都不说,对不同的场景有不同的实现方式.版主告诉你的方式,如果是internet,那就不一定适用了,因为有防火墙,有路由器,有动态IP.在这种情况下HttpListener 是肯定不可行的.而TcpListener又受到路由器的inbound限制.

    服务器怎么判断是否有信息,也是根据不同的场景有不同的方式,这得看你是什么样的需求,用不用数据库都还不一定.

    用什么数据库,也还有不同的实现模式.

    2010年5月27日 7:41
  • 通讯协议不限;局域网环境;客户端需要登录;根据用户,服务器将信息推送到客户端;数据量不大,几十个字。
    2010年5月27日 8:05
  • 通讯协议不限;局域网环境;客户端需要登录;根据用户,服务器将信息推送到客户端;数据量不大,几十个字。


    考虑采用 WCF 写一个发布/订阅服务,使用 TcpBinding,采用 WCF 回调发送通知给客户端.

    更新机制:

    1,发布服务的发布接口中直接调用所有活动的客户端回调;

    2,发布服务将信息写入数据库,然后再读取新信息发送给客户端;

    第一种方式需要额外的服务以支持负载均衡模型,简单的说,你有多个"发布-订阅"服务(Pub-Sub),一个"订阅管理"服务(SubMgr).

    所有客户端向Pub-Sub订阅消息,所有Pub-Sub向 SubMgr 订阅消息;所有客户端发布到Pub-Sub上的新消息都会被发布到SubMgr,SubMgr再将新消息发布到所有订阅该消息的Pub-Sub上,然后各Pub-Sub再将消息发布给各自持有的客户端.

    第二种方式,依赖数据库本身的机制,比如支持Dependency的Sql ,Oracle,这样的话,前面叙述的SubMgr就可以由数据库来担当.在实际使用中,Sql 没 Oracle好使.如果无法实现数据库级别的Dependency的话,则考虑通过Pub-Sub去轮询访问数据库.当然,好的方式是,由SubMgr去轮讯,让后将信息发布给各pub-Sub.

    另外,你还需要考虑持久订阅的问题,客户端未在线的时间内发布的信息是否需要在客户下次登录时发布给客户.如果需要,则需要通过数据库建立持久订阅管理容器,当每次客户登录时,都需要检查客户未接收过的消息,并发送给客户端.

    2010年5月27日 9:11
  • 发布-订阅"服务(Pub-Sub),一个"订阅管理"服务(SubMgr)没接触过;有没有相关的文档,基于.net 4.0最好
    2010年5月28日 0:26