未发布 网络通讯控件PowerSNMP for .NET常见问题合集 PowerSNMP for .NET是用于监视和控制网络设备创建自定义的SNMP管理器。简单网络管理协议（SNMP）采用线程通信机制，安全强、并且具有编码/解码功能，您可以快速开发定制SNMP应用程序。由于开发此工具需要的资源少，灵活性好，所以便于重新使用和维护。
问：PowerSNMP for .NET与其他SNMP产品有什么不同？
答：最新版本的PowerSNMP产品线增加了新的.NET 2.0重新设计，利用新的.NET环境的强大功能，提供了最先进的Internet Communications组件。包含以下功能：- SNMP版本1，2和3包含认证、加密/解密
- RFC 1155,1157,1158,1213,2578,2579,3417和3418中定义的内置对象、标识符、表格、通知和组
- MIB解析，自定义MIB文件可用于在源代码中生成C＃或VB类
- MIB编译，自定义MIB文件可用于在运行时生成动态类和对象
- 可轻松实现多线程应用程序的启动方法
- EncodedMessage属性，用于轻松调试发送和接收的字节以及会话记录
.NET环境已经发展，用户也是如此。客户正在开发更多的ASP.NET应用程序，更多的控制台应用程序和更多的服务应用程序。缺乏UI、伪阻塞和异步方法与这些环境无关。由于这些原因，PowerSNMP for .NET 4.x设计有以下重点：
- 改进异步支持：传统的PowerSNMP异步支持提供了一种在工作线程上执行的方法，但这需要一个信号机制来指示何时完成操作。这导致了难以维护的事件驱动代码。通过新的设计，代码占用更少的资源并且更加灵活。
- 改进.NET 2.0功能：PowerSNMP 4.x已经充分利用了.NET 2.0中引入功能。现在大多数用户已经从.NET 1.x迁移，可以升级PowerSNMP并兼顾兼容性。当然，.NET 1.x产品线仍可在.NET 1.x环境中使 用以支持旧版应用程序。
- 支持.NET CF（Compact Framework）：通过新的设计，全面支持Compact Framework。
问：试用版与许可版本有什么不同？
答：在开发期间，产品“试用”版本和许可版本之间没有区别。
在运行时，没有有效的开发者许可证创建的应用程序将定期显示一条试用消息。除了这个消息之外，功能没有区别。问：示例是否随产品一起发送？
答：当然。我们发送将CSharp和Visual Basic .NET中的完整应用程序（不仅仅是简单的技术演示）作为Windows应用程序和Web应用程序。
问：PowerSNMP是否完全支持从表格中获取值？GetBulk怎么样？
答：以上都支持。PowerSNMP包括高级表格检索方法，完全支持版本2命令（如GetBulk）。
问：应用程序如何使用Manager控件？
答：一个典型的应用程序会将所有代理的IP地址存储在网络上，并且会按照时间表从代理收集统计信息。应用程序的地址也可能会被注册到代理以设置陷阱，因此管理员将以异步方式（动态地）通知重要的代理事件。信息将被记录到文件中，并通过用户界面动态显示。
问：应用程序如何使用代理控件？
答：假设PC主机正用于控制硬件设备。你可以创建一个代理，被查询时将通过硬件设备的统计信息进行响应。该概念可以扩展到提供由主机收集和提供的任何类型的信息（使用SNMP标准）。
问：我可以创建一个作为Microsoft操作系统代理的子代理吗？
答：通常不能。代理商通常使用“知名”端口161进行通信。由于Microsoft的代理将使用此端口，你的应用程序将必须使用非标准端口，并且你的管理器必须配置为检查你的非标准端口（可以在某些情况下进行，但不常见）。
问：当我建立VS.NET 2008 Website时，为什么会出现“尝试反序列化一个空的流”的异常？
答：网站为组件许可创建一个App_Licenses.dll，必须与应用程序一起分发。由于一个明显的VS.NET 2008错误，这个dll在64位操作系统编译时是错误的。为了解决这个问题，可以更换2008 Website中的App_Licenses dll。
选项包括：
a）使用相同的控件/组件在相同（许可）机器上编译2005 Website
b）在32位计算机上编译2005或2008 WebSite，前提是该机器也获得许可（Dart Developer许可证允许安装在最多两台机器）
从以上的选项中选一个替换有缺陷的App_Licenses.dlll，并且网站应该在没有问题的情况下构建和部署。不要删除新的dll，否则VS.NET将再次创建错误的dll。
未发布 MailBee.NET Objects显示HTML/纯文本邮件教程（三）：在Web应用程序中显示 MailBee.NET Objects是一款为创建、发送、接收以及处理电子邮件而设计的健壮、功能丰富的.NET控件。几行代码便可为应用程序添加E-Mail支持，简单高效。具备“必需”以及独特的功能，这些控件帮助开发人员简单快速地将复杂的电子邮件功能添加到他们的应用程序中。
本文主要介绍了在Web应用程序中显示HTML/纯文本邮件的代码示例。目前MailBee.NET Objects在线订购享75折优惠正在进行中，欢迎您下载试用版进行运用！
由于Web应用程序在呈现HTML而不是纯文本的Web浏览器中运行，因此应将纯文本数据转换为HTML，以便在浏览器中查看此数据。这也适用于在HTML容器中渲染数据的桌面应用程序。
MailBee可以邮件解析期间自动将纯文本内容转换为HTML。为了调整邮件解析过程，MailMessage类提供了Parser属性。
C＃
MailMessage msg = pop.DownloadEntireMessage(1);
msg.Parser.PlainToHtmlMode = PlainToHtmlAutoConvert.IfNoHtml;
VB.NET
Dim msg As MailMessage = pop.DownloadEntireMessage(1)
msg.Parser.PlainToHtmlMode = PlainToHtmlAutoConvert.IfNoHtml
上面的节点从服务器中下载邮件，并让MailBee自动将邮件的纯文本转换为HTML（如果邮件还没有HTML版本）。因此，你将得到可以在ASP.NET应用程序中显示的HTML邮件，如下所示：
C＃
Response.Write(msg.BodyHtmlText);
VB.NET
Response.Write(msg.BodyHtmlText)
如果你还需要在HTML容器中显示邮件标头，你可以使用HeadersAsHtml属性替换邮件的所有标题中的“<”，“>”，“和”和“”字符，其HTML表示形式为：
C＃
msg.Parser.HeadersAsHtml = true;
Response.Write("From: " + msg.From.ToString());
VB.NET
msg.Parser.HeadersAsHtml = True
Response.Write("From: " + msg.From.ToString())
未发布 ReactOS：基于Windows的开源操作系统 ReactOS是一个免费开源的全新操作系统，其设计基于Windows，就像Linux基于Unix一样。ReactOS的外观和Windows类似，可以运行Windows软件和驱动，不过，该项目正在进行当中，可能尚无法完美兼容，最好的方法是在虚拟机上安装ReactOS，检查兼容性。
ReactOS使用X.Y.Z版本命名方案：X表示项目是否达到预期目标，Y表示大版本（关键特性和增强），Z表示小版本（Bug修复和一般开发）。第一个有文档记录的版本是0.0.7，发布于1998年7月。
作为开源项目，由于社区开发人员的数量不固定，所以ReactOS没有一个固定的路线图。不过，他们会尽量在二到六个月发布一个版本。0.4.0、0.5.0和1.0.0是当前设置的里程碑版本。0.4系列版本是最后的Alpha版本，从0.5系列版本开始，项目将进入Beta测试阶段，1.0及以上版本表明该项目已经可供日常使用了。
ReactOS 0.4.6已于近日发布。该版本向真正的硬件支持迈出了重要的一步。若干双启动问题得到了解决，分区管理的安全性得到了提高，可以避免分区列表结构的冲突。ReactOS Loader现在可以加载自定义内核和HAL了。
在0.4.6中，打印子系统尚不成熟，但Colin Finck已经实现了大量新的API，并修复了一些自动化测试中暴露出的Bug。
在驱动方面，Pierre Schweitzer为其增加了NFS驱动程序，并开始实现RDBSS和RXCE，将来还会支持SMB。Sylvain Petreolle为其引入了数字电视调谐器驱动。UDFS、CDFS、SCSI和HDAUDBUS中的若干Bug也得到了修复。
在兼容性方面，0.4.6引入了一个shim引擎，作为新应用程序兼容框架的一部分。在这个版本中，该引擎默认关闭，可以通过ReactOS注册表启用。该版本还包含一个专门的NTDLL库，可以为比较新的软件提供一些它们需要的NTDLL Vista+函数。
ReactOS 0.4.6还改进了用户体验，并修复了多个内存管理、ntoskrnl和文件系统的Bug，变得更加稳定。
未发布 百度正式开源其RPC框架brpc 9月14日，百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。
brpc开发于2014年，主要使用的语言是C++和Java，是百度内部使用最为广泛的RPC框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约75万个同时在线的实例。据了解，百度内部曾有多款RPC框架，甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ记者采访了brpc负责人戈君。
Q：谈谈brpc的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？
戈君：brpc于2014年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc一共进行了3000次左右的改动，现在仍在持续优化中，百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java，对其他语言的支持主要是通过包装C++版本，比如brpc的Python版包含C++版的大部分功能。
brpc目前支撑百度内部大约75万个同时在线的实例（不含client），超过500种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
Q：为什么百度当时要研发brpc？
戈君：我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki可能是百度内被点赞最多的内容之一。
Q：与其他的一些开源的RPC框架相比，brpc的优势是什么？
戈君：brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼，什么都做。另一方面我们也注意到gRPC（包括更早的Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
RPC真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc是如何做的呢？
- 可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
- 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
- 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。
Q：作为公司内部的RPC框架，在服务治理方面有什么考虑？
戈君：百度内部RPC使用非常广泛，基本都是RPC调用，一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是BCLOUD，发布是Agile，服务注册和发现是BNS，认证是Giano，监控和运维是NOAH。在百度内部，brpc和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。
Q：之前百度还开源过sofa-pbrpc，brpc与它的区别是什么？
戈君：sofa-pbrpc也是百度开发的一个比较早期的RPC框架，属于sofa编程框架的一部分，在搜索有应用。brpc相比sofa-pbrpc有如下优点:
- 对协议的抽象更一般化，并统一了全百度的通信架构。bprc能容纳非常多的协议，基于Protobuf的，基于HTTP的，百度内的nshead/mcpack，开源的Redis/Memcached，甚至RTMP/FLV/HLS直播协议，brpc能逐渐地嵌入现有系统，而不需要彻底重构，但sofa-pbrpc则不具备扩展协议的能力。类似的，sofa-pbrpc也无法定制负载均衡算法，brpc默认提供round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。
- 多线程质量更好。多线程编程是非常困难的，看起来简单的RPC遍布多线程陷阱，比如处理超时的代码可能在RPC还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步RPC的回调里发起一个同步RPC会发生什么，带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
- 完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序，查看连接，在线修改gflags，追踪RPC，分析CPU热点，内存分配，锁竞争等一应俱全。
无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc和其他已经开源的RPC框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。
Q：谈谈brpc的整体架构？
戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如brpc支持非常多的协议，在百度内部一个brpc server同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。
Client端的协议也非常多，用户用brpc和bthread用得很爽，所以希望我们最好能统一所有的客户端，像对Redis和Memcached的客户端支持也是在这个背景下做的，这两个客户端比官方Client好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如HTTP就是把ChannelOptions.protocol设为“http”，Redis就是“redis”。Server端甚至不用设，它会自动判断每个client的协议，怎么做到的开源文档里也有。
名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的”乙方”，但我们也是严厉的”乙方”。
Q：brpc的性能如何？这么高的性能是怎么做到的？
戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用brpc靠什么？最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：
- 百度地图API入口
- 联盟DSP
- ELF学习框架
- 云平台代理服务
Q：为什么要将brpc开源？接下来在开源项目的迭代方面有什么计划吗？
戈君：因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于brpc的RAFT库，搭建高可用分布式系统非常方便；以及使用brpc的bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从Apollo、PaddlePaddle开始，百度真的开始拥抱开源了。brpc的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析RPC技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。
查看更多资讯>>>
未发布 【教程】Edraw Max（亿图图示）：思维导图怎样一次性键入分支内容？ Edraw Max（亿图图示）作为一款功能齐全，使用方便、快捷的全类型图形图表设计软件，不仅富含丰富的模板和例子，还可以一键轻松导入思维导图的分支内容。本文就教大家具体的操作方法吧!
目前Edraw Max（亿图图示）在线订购享75折优惠活动正在进行中，欢迎您下载、购买进行运用！
第一步：选中需要添加分支的主题形状，然后点击“思维导图”菜单栏下的“添加多个主题”；
第二步：打开之后，依次输入需要添加的分支内容，按回车键(enter)换行，每一行代表一个主题；
第三步：重复以上两步，可以在第二级分支上再一次导入第三级分支；
第四步：数据导入之后，可以跟通过“思维导图”下的“布局”对整个思维导图的主题、样式进行调整，同时还可以将数据直接导出为Word、Excel以及文本格式。
图标隐藏鼠标指针。可通过双击幻灯中或在“幻灯片|选择鼠标指针
沪公网安备31011202009668号 | 沪ICP备13020027号-2