对称加密算法
对称加密算法是应用较早的加密算法，技术成熟。在对称加密算法中，数据发信方将明文（原始数据）和加密密钥（mi yao）一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。 简介 对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。它要求发送方和接收方在安全通信之前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信性至关重要。 2特点 对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。 不足之处是，交易双方都使用同样钥匙，安全性得不到保证。此外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增长，密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。而与公开密钥加密算法比起来，对称加密算法能够提供加密和认证却缺乏了签名功能，使得使用范围有所缩小。在计算机专网系统中广泛使用的对称加密算法有DES和IDEA等。美国国家标准局倡导的AES即将作为新标准取代DES。 3具体算法 DES算法，3DES算法，TDEA算法，Blowfish算法，RC5算法，IDEA算法。 4原理应用 对称加密算法的优点在于加解密的高速度和使用长密钥时的难破解性。假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。对称加密算法的安全性取决于加密密钥的保存情况，但要求企业中每一个持有密钥的人都保守秘密是不可能的，他们通常会有意无意的把密钥泄漏出去——如果一个用户使用的密钥被入侵者所获得，入侵者便可以读取该用户密钥加密的所有文档，如果整个企业共用一个加密密钥，那整个企业文档的保密性便无从谈起。DESCryptoServiceProvider RC2CryptoServiceProvider RijndaelManaged TripleDESCryptoServiceProvider //例加密文本文件(RijndaelManaged ) byte[] key = { 24, 55, 102,24, 98, 26, 67, 29, 84, 19, 37, 118, 104, 85, 121, 27, 93, 86, 24, 55, 102, 24,98, 26, 67, 29, 9, 2, 49, 69, 73, 92 }; byte[] IV ={ 22, 56, 82, 77, 84, 31, 74, 24,55, 102, 24, 98, 26, 67, 29, 99 }; RijndaelManaged myRijndael = new RijndaelManaged(); FileStream fsOut = File.Open(strOutName, FileMode.Create,FileAccess.Write);//strOutName文件名及路径 FileStream fsIn = File.Open(strPath, FileMode.Open,FileAccess.Read); CryptoStream csDecrypt=new […]
View Details不对称加密算法
不对称加密算法使用两把完全不同但又是完全匹配的一对钥匙—公钥和私钥。在使用不对称加密算法加密文件时，只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。 加密原理 加密明文时采用公钥加密，解密密文时使用私钥才能完成，而且发信方（加密者）知道收信方的公钥，只有收信方（解密者）才是唯一知道自己私钥的人。不对称加密算法的基本原理是，如果发信方想发送只有收信方才能解读的加密信息，发信方必须首先知道收信方的公钥，然后利用收信方的公钥来加密原文；收信方收到加密密文后，使用自己的私钥才能解密密文。显然，采用不对称加密算法，收发信双方在通信之前，收信方必须将自己早已随机生成的公钥送给发信方，而自己保留私钥。由于不对称算法拥有两个密钥，因而特别适用于分布式系统中的数据加密。广泛应用的不对称加密算法有RSA算法和美国国家标准局提出的DSA。以不对称加密算法为基础的加密技术应用非常广泛。 2与对称加密的比较 与对称加密算法的不同 与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私 有 密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加 密，只有用对应的私有密钥才能解密；因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。 非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。 非对称加密算法的保密性比较好，它消除了最终用户交换密钥的需要，但加密和解密花费时间长、速度慢，它不适合于对文件加密而只适用于对少量数据进行加密。 经典的非对称加密算法如RSA算法等安全性都相当高 对称加密 对称加密算法是应用较早的加密算法，技术成熟。在对称加密算法中，数据发信方将明文（原始数据）和加密密钥一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。此外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量成几何级数增长，密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。在计算机专网系统中广泛使用的对称加密算法有DES、IDEA和AES。 DES 传统的DES由于只有56位的密钥，因此已经不适应当今分布式开放网络对数据加密安全性的要求。1997年RSA数据安全公司发起了一项“DES挑战赛”的活动，志愿者四次分别用四个月、41天、56个小时和22个小时破解了其用56位密钥DES算法加密的密文。即DES加密算法在计算机速度提升后的今天被认为是不安全的。 AES AES是美国联邦政府采用的商业及政府数据加密标准，预计将在未来几十年里代替DES在各个领域中得到广泛应用。AES提供128位密钥，因此，128位AES的加密强度是56位DES加密强度的1021倍还多。假设可以制造一部可以在1秒内破解DES密码的机器，那么使用这台机器破解一个128位AES密码需要大约149亿万年的时间。（更深一步比较而言，宇宙一般被认为存在了还不到200亿年）因此可以预计，美国国家标准局倡导的AES即将作为新标准取代DES。 from:http://baike.baidu.com/view/7595.htm
View DetailsSystem.Security.Cryptography 命名空间
System.Security.Cryptography 命名空间提供加密服务，包括安全的数据编码和解码，以及许多其他操作，例如散列法、随机数字生成和消息身份验证。 有关更多信息，请参见加密服务。 类 类 说明 Aes 表示高级加密标准 (AES) 的所有实现都必须从中继承的抽象基类。 AesCryptoServiceProvider 使用高级加密标准 (AES) 算法的加密应用程序编程接口 (CAPI) 实现来执行对称加密和解密。 AesManaged 提供高级加密标准 (AES) 对称算法的托管实现。 AsnEncodedData 表示 Abstract Syntax Notation One (ASN.1) 编码数据。 AsnEncodedDataCollection 表示 AsnEncodedData 对象的集合。 此类不能被继承。 AsnEncodedDataEnumerator 提供在 AsnEncodedDataCollection 对象中导航的能力。 此类不能被继承。 AsymmetricAlgorithm 表示所有非对称算法的实现都必须从中继承的抽象基类。 AsymmetricKeyExchangeDeformatter 表示所有非对称密钥交换反格式化程序均从中派生的基类。 AsymmetricKeyExchangeFormatter 表示所有非对称密钥交换格式化程序均从中派生的基类。 AsymmetricSignatureDeformatter 表示所有不对称签名反格式化程序实现均从中派生的抽象基类。 AsymmetricSignatureFormatter 表示所有不对称签名格式化程序实现均从中派生的基类。 CngAlgorithm 封装加密算法的名称。 CngAlgorithmGroup 封装加密算法组的名称。 CngKey 定义与下一代加密技术 (CNG) 对象一起使用的密钥的核心功能。 CngKeyBlobFormat 指定与 Microsoft 下一代加密技术 (CNG) 对象一起使用的密钥 BLOB 格式。 CngKeyCreationParameters 包含密钥创建的高级属性。 CngPropertyCollection 提供下一代加密技术 (CNG) 属性的强类型集合。 CngProvider 封装与下一代加密技术 (CNG) 对象一起使用的密钥存储提供程序 (KSP) 的名称。 CngUIPolicy 为用户界面 (UI) 封装可选配置参数，当您访问受保护的密钥时，下一代加密技术 (CNG) 将显示这些配置参数。 CryptoAPITransform 执行数据的加密转换。 此类不能被继承。 CryptoConfig 访问加密配置信息。 CryptographicAttributeObject […]
View DetailsAES（Rijndael）算法的 JavaScript 源代码
下面的内容来自 Rijndael in JavaScript。 下面的代码是 Rijndael 算法的 JavaScript 实现。它可以在 IE4+、NS4+ 以及任何兼容 ECMAScript 第一版的浏览器中运行。这个实现没有进行优化，也就是说它不适合处理大量的数据（比如多于几 KB）和需要高速运行的应用程序中。 下载: rijndael.js /* rijndael.js Rijndael Reference Implementation Copyright (c) 2001 Fritz Schneider This software is provided as-is, without express or implied warranty. Permission to use, copy, modify, distribute or sell this software, with or without fee, for any purpose and by any individual or organization, is hereby granted, provided that the above copyright notice and this paragraph appear in all copies. Distribution as a part of an application or binary must […]
View Details微软到底从 Android 上捞了多少好处？
微软长期以来依靠自己的大批专利数向Android手机厂商收取巨额的专利费已经不是什么秘密了。早在2011年就有消息称微软当时和三星谈判谋求 签订一份让三星每出货一部Android手机就向微软支付15美元专利费的协议，三星方面则期望通过加深和微软Windows Phone平台的合作以换取将该费用降低至10美元每台的结果。从中我们可以看到微软和三星之间的博弈，其中涉及到很多商业问题。 在2014年10月份披露的一份诉讼文件显示微软每年从从Android和Chrome OS上所获取的专利授权收入非常惊人，仅三星一家公司，2013年就向微软支付了高达10亿美元的专利授权费用。而除了最大且最成功的Android厂 家，还有数十家公司向微软支付了Android专利使用费。要知道微软设备娱乐部门(包括Xbox、Windows Phone、以及Skype)在2013年的利润仅仅为8.48亿美元，三星一家在2013年交给微软的专利费就超过了这个数字。 不仅仅是三星，微软和HTC，摩托罗拉等公司也有有类似的交易，每出售一台Android设备需要向微软缴纳一定的专利费。不仅手机厂商，甚至像 Barnes & Noble这样专营电子书业务的公司生产搭载 Android 系统的电子书阅读器也需要向微软支付专利费。 为何手机厂商用Android却要付给微软专利费？ 我们都知道Android是基于Linux的自由及开放源代码的操作系统，而早在Android没有单身之前微软就已经在Linux系统上获取专利授权费用了。所以微软拿Android系统开刀也是再正常不过的事情。 2007年Android还没正式与世人见面，微软在当年就宣称Linux侵犯了自己的 235 项专利，但是微软没有正式公布和表明Linux那些地方侵犯了自己的专利。微软的一贯策略是直接和那些应用Linux技术的公司谈判，签署专利授权协议。 包Amazon、Novell、Linspire、TurboLinux在内的多家大公司都已经和微软签有专利授权协议，以保护公司和用户的利益。也有一 些在自己设备中利用到Linux内核的厂商，在受到微软的威逼之后直接选择从设备种移除相关功能，比如TomTom。 还有一个有趣段子是这样的：上个世纪80年代当时的巨头IBM曾经向Sun Microsystems（目前已经被甲骨文收购）索取专利费用，声称Sun侵犯了IBM的7项专利并要求支付赔偿。但是经过Sun的认真核查发现涉案的 7件专利后发现其中6件很可能是无效的，而且 Sun 很明显也没有侵犯 IBM 所提到的第7件专利。但是结果很出人意料，IBM方面宣称也许你们真的没有侵犯我们刚刚提到的那7件专利，但是我们在美国有1万件专利，你难道真的想让我们空手回去再查查看你们是不是侵犯了我们的其他专利吗？ 最后经过一番博弈，Sun Microsystems最后还是向IBM支付了数额不菲的“专利保护费”。而IBM则继续去其他公司收保护费去了。而谷歌的Android现在就面临着微软给出的一个类似的难题。这保护费你交定是不交？ Android设备到底侵犯了微软的什么专利？ 当然也有不愿意交的，比如摩托罗拉。因此微软不得不把一些专利内容向法院上呈。 1、专利号5579517，长文件名支持。第 5 版之前的 MS-DOS 仅支持 11 个字符的文件名（包括扩展名在内），所以微软发明了一种同时支持长文件名和短文件名的方法。使用过 DOS 操作系统的朋友应该知道，超过11个字符的文件名DOS会自动缩短，并用～符号替代一部分，这个专利就是关于这个实现的。由于 Android 系统支持 FAT 格式的 MicroSD (TF) 卡，所以在卡上存储的数据必然要支持 DOS 长文件名，换句话说，任何一个支持 FAT 格式的设备，都受到微软此专利的限制。 2、专利号6621746，闪存擦除。监视闪存的使用状况，在适当的时候进行有针对性的擦除操作。严格的说来，任何一个基于 Flash 的文件系统必然要实现类似的功能，Android 自然也不例外。 3、专利号6909910，联系人的创建和更新。具体为从通话记录中更新某个联系人或创建新联系人的系统和方法。如下图，这个估计很多智能手机都逃不过：微软有关联系人新建和更新的专利。 4、专利号7644376，系统状态监视和通知系统。主要是关于允许移动应用获取手机状态变化的 API，管理全局系统状态通知。 5、专利号5664133，弹出式上下文菜单系统。具体专利描述为对用户选择的对象获取并展示一系列命令在一个弹出菜单中。这专利估计是微软的屠龙刀，神挡杀神，佛挡杀佛。当初苹果引入右键菜单的时候，微软没有起诉是因为微软和苹果签署有专利交叉使用互不起诉的协议。 6、专利号6578054，增量同步。用来同步服务器和客户端里多个数据副本的系统和方法，通过此方法某一个数据副本的增量变化将会被识别，传输，整合到其他所有数据副本上。按照这个专利描述，Android的数据同步功能可以说全军覆没。 7、专利号6370566，从移动设备发起计划会议请求。专利里描述的实现方式和Google Calendar并不相同，所以不太明白这个和Android哪里冲突了。 可以看出以上微软所列出的专利其实都是一些普遍应用在智能手机操作系统甚至是桌面操作系统上的基础性功能，在一些功能上用户已经非常习惯于这种操作 方式和逻辑，如果要绕口这些专利意味着要退出当前的显示界面，重新制造一个用户和开发者都陌生的新环境，这对计算机行业来说其实是一种悲哀。 谷歌如何才能用Android赚更多的钱？ 前面说到微软在Android手机生产商手里收取了巨额的专利费。那么谷歌呢，身为 Android 平台的拥有者谷歌在Android平台上又获得了多少利益呢？ 首先我们要明确Android系统它不像微软的Windows系统和苹果的iOS系统，当PC和手机制造商使用Windows系统应用到自己的电脑和手机及平板电脑上时微软是要收取授权费的。而苹果虽然不出售自己的系统，但是 iOS 除了苹果本身以外谁也别想用。 Android系统本身就是一个开放式的系统。任何生产商，不管是手机，电脑还是家电厂商将 Android 系统预装到硬件设备上，谷歌实际上未收取任何费用。谷歌的策略是尽可能的把Android系统渗透到更多的消费人群当中，这些人会通过谷歌的搜索，然后点 击谷歌搜索的广告，（这一点上说谷歌在中国基本是一毛钱也捞不到）谷歌从而收益。但 Android 在广告上并没有给谷歌带来非常可观的收入。 有一组数据：谷歌2014年移动搜索业务营收为118亿美元，其中75%的营收（89亿美元）来自使用iPhone和iPad的网站搜索。这意味 着，谷歌2014年在Android设备上的搜索业务营收仅有30亿美元。与谷歌2014年的660亿美元收入相比，30亿美元似乎显得微不足道。另外一 个数字可能领谷歌更加汗颜，仅2014年第四季度，Facebook的移动广告营收就超过26.5亿美元。 谷歌自己创造出来的东西却让别人赚了大钱，谷歌或许是时候更多的想想如何利用这数十亿的Android设备来为自己创造更多的价值。 出处：威锋网 from:http://www.oschina.net/news/61425/microsoft-get-profit-from-android
View Details再来 20+ 个超棒的扁平 UI 工具包的 PSD 设计
很漂亮的扁平 UI 的 PSD 设计原稿，免费的！ PSD Freebie UI Kit View | Source Flat Design UI Components View | Source Vertical Infinity – A Mega Flat Style UI Kit View | Source Sven – Modern PSD Ui Kit View | Source Flat UI Kit View | Source Flat Rounded Square UI Kit View | Source Flatex UI Kit Pro v1.0 View | Source Avengers Flat UI Kit View | Source Orange/Cyan UI View | Source Color UI Kit View | […]
View Details共收录 开源中国 的 10 款开源软件，第 1 页
OSCHINA Android 客户端 这是 OSCHINA 官方开发的 Android 客户端软件，采用原生 API 开发，非 HTML 模式。 采用 GPL 授权协议，鼓励你在这基础上进行修改和完善，并与大家分享你的版本。 下载官方版本：http://www.oschina.net/app…更多OSCHINA Android 客户端信息 最近更新： OSC安卓客户端2.0.5发布，支持Team团队协作 发布于 4周前 OSCHINA iPhone 客户端 这是 OSCHINA 官方开发的 iPhone 客户端软件，采用原生 API 开发，非 HTML 模式。 采用 GPL 授权协议，鼓励你在这基础上进行修改和完善，并与大家分享你的版本。 下载官方版本：http://www.oschina.net/app…更多OSCHINA iPhone 客户端信息 最近更新： OSCHINA iPhone 客户端 3.0 全新版本发布 发布于 2周前 开源中国代码托管 Git@OSC Git@OSC 是开源中国社区推出的基于 Git 的代码托管服务。托管到 Git@OSC 的开源项目还可以参加中国源推广计划。Git@OSC 在 GitLab 开源软件基础上做了大量的定制开发。更多Git@OSC信息 最近更新： Git@OSC 项目推荐 —— 轻量化的分布式服务框架 发布于 1天前 Java两级缓存框架 J2Cache J2Cache 是 OSChina 目前正在使用的两级缓存框架。第一级缓存使用 Ehcache，第二级缓存使用 Redis 。由于大量的缓存读取会导致 L2 的网络成为整个系统的瓶颈，因此 L1 的目标是降低对 L2 的读取次数。该缓存框架主要用于集群环境中。单机也可使用，用于避免…更多J2Cache信息 最近更新： 【每日一博】吐槽一下 J2Cache 两级缓存框架 发布于 4周前 前端代码编辑和分享平台 RunJS 在线编辑、展示、分享、交流你的 JavaScript 代码 RunJS 是一个在线的 HTML、Javascript、CSS 等 web 前端代码的编辑分享平台，拥有实时预览、高亮显示、代码格式化等功能，我们提供 OSChina、微博、qq、github、google、yahoo、hotmail这七种登录方式，…更多RunJS信息 最近更新： OSC 第 […]
View Details共收录 360 的 9 款开源软件，第 1 页
MySQL中间层 Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。目前该项目在360公司内部得到了广泛应用，很多MySQL业务已经接入了A…更多Atlas信息 最近更新： 【开源访谈】Atlas 作者 朱超 访谈实录 发布于 1年前 高性能NoSQL数据库 SSDB SSDB 是一个 C/C++ 语言开发的高性能 NoSQL 数据库, 支持 zset(sorted set), map(hash), kv, list 等数据结构, 用来替代或者与 Redis 配合存储十亿级别列表的数据. SSDB 在 QIHU 360 被大量使用, 同时也被国内外业界的众多互联网企业所使用. SSDB 支持 PH…更多SSDB信息 最近更新： Git@OSC 项目推荐 —— SSDB 高性能 NoSQL 发布于 2周前 PHP执行流程跟踪工具 phptrace phptrace 是一个追踪（trace）PHP执行流程的工具，你如果用过strace的话，则可能很容易想到phptrace到底实现了什么样的功能。 其实，phptrace是类strace的一个实现，不同的是，strace用来追踪系统调用，而phptrace用来追踪PHP函数调用。无论是开发测试 还是…更多phptrace信息 最近更新： phptrace —— 来自 360 的 PHP 执行流程跟踪 发布于 4个月前 基于Promise的Node.js MVC框架 thinkjs thinkjs 是一个快速、简单的基于MVC和面向对象的轻量级Node.js开发框架，遵循MIT协议发布。秉承简洁易用的设计原则，在保持出色的性能和至简的代码同时，注重开发体验和易用性，为WEB应用开发提供强有力的支持。 thinkjs里面很多特性来源于ThinkPHP，同时根…更多thinkjs信息 最近更新： thinkjs 1.0 发布，Node.js 的 MVC 框架 发布于 7个月前 对象缓存服务器 kmemcache 分布式linux内核内存对象缓存服务器，实现基于memcached v1.4.15，基本兼容memcached的所有操作。经初步测试，内存数据操作比memcached快1倍，网络并发量比memcached的也大许多，目前处于alpha版本。 优点：由于在内核的socket层实现，所有处理网络事件性能…更多kmemcache信息 分布式配置管理工具 QConf […]
View Details共收录 东软 的 2 款开源软件，第 1 页
Nginx 安全增强版本 SEnginx 什么是SEnginx？ SEnginx（Security Enhanced NGINX）是著名的 HTTP 和 反向代理 服务器nginx的一个变种版本，主要是在原版nginx的基础上增加了多种Web安全功能，并增强了应用交付等方面的原有功能。SEnginx继承了nginx的全部原始特性，全面兼容标准nginx…更多SEnginx信息 最近更新： SEnginx 主线版本 1.6.2 发布 发布于 1个月前 OpenStack LBaaS 驱动 ADSG-LBaaS-Driver 东软ADSG(应用交付安全网关，Application Delivery Security Gateway) LBaaS Driver 当前实现了对 OpenStack （Havana 版本或更高）负载均衡即服务（Load Balancer as a Service， LBaaS ）的支持。通过将一个 LBaaS 驱动集成到 OpenStack LBaaS 组件中，…更多ADSG-LBaaS-Driver信息 最近更新： 来自东软的 OpenStack 负载均衡即服务开源项目 发布于 2个月前 from:http://www.oschina.net/project/neusoft
View Details共收录 华为 的 4 款开源软件，第 1 页
HBase 二级索引 hindex hindex 是华为公司开发的纯 Java 编写的 HBase 二级索引，兼容 Apache HBase 0.94.8。 当前的特性如下： 多个表索引 多个列索引 基于部分列值的索引 使用索引扫描等于和范围条件 批量加载数据来索引表（索引完成批量加载） 工作原理 HBase 二级索引是 100%…更多hindex信息 最近更新： hindex —— 来自华为的 HBase 二级索引 发布于 8个月前 ARM 开放平台规范 96Boards 96Boards 是 ARM 开放平台规范，是第一个定义 Cortex-A 开发板的开放规范，Cortex-A 是 ARM SoC 供应商提供的低耗能，小脚本 32 位和 64 位开发板。标准化扩展 Peripheral I/O 总线，显示和相机，允许硬件生态系统开发一系列兼容组件的产品，在其生命周期可…更多96Boards信息 虚拟交换机 POFSwitch POFSwitch是由华为公司采用BSD许可基于Linux系统C语言实现的虚拟交换机，POFSwitch与POFController协同工作增强OpenFlow协议支持协议无感知转发。更多POFSwitch信息 OpenFlow控制器 POFController POFController是由华为公司采用BSD/ Apache授权基于Java语言实现的OpenFlow控制器，提供了一个GUI管理界面，用于交换机的控制和配置。POF主要包含控制器和交换机两个 原型文件，旨在提高OpenFlow的规范及支持无感知转发协议和数据包格式。…更多POFController信息 from:http://www.oschina.net/project/huawei
View Details