服务器

为什么将此方法特别弄一个专集，因为在通信软件领域中，数据接收一直是一个比较有复杂的事情，处理的好不好，直接影响到程序效率。 本文就是为了介绍NetHost::Recv配合mdk这套引擎，如何方便的解决了传统通信软件中在数据接收这一块上遇到的各种瓶颈 瓶颈1：等待数据的方式 循环sleep、阻塞recv、事件触发（例如select epoll） 他们的缺点 循环sleepcpu吃紧 阻塞recv占用业务线程 事件触发，不知道有多少可读数据，如果数据不完整，读出数据需要用户自己维护 NetHost的解决方案 NetHost有自己的接收缓冲，mdk引擎收到数据首先放入NetHost的接收缓冲，然后触发OnMsg。 因为底层已经在接收了，所以recv永不阻塞，数据不够直接返回，等下次数据到达时，OnMsg会再次被触发 瓶颈2：一个完整消息被分成多次到达 来1次收1次，记录上次接收状态，用户自己拼包 缺点 用户得自己维护已接收的数据，相当于一个接收缓冲，这个缓冲必须随着连接的建立与断开创建与删除，维护代价昂贵 NetHost的解决方案 NetHost::Recv比传统的recv方法增加一个bClearCache参数，告诉Recv接收到数据后，是否将数据从接收缓冲删除 bClearCache为true时，与传统recv方法效果一样，比如到达数据123456789 recv 2 byte

4.7 Gitosis 把所有用户的公钥保存在 authorized_keys 文件的做法，只能凑和一阵子，当用户数量达到几百人的规模时，管理起来就会十分痛苦。每次改删用户都必须登录服务器不去说，这种做法还缺少必要的权限管理 — 每个人都对所有项目拥有完整的读写权限。 幸好我们还可以选择应用广泛的 Gitosis 项目。简单地说，Gitosis 就是一套用来管理 authorized_keys 文件和实现简单连接限制的脚本。有趣的是，用来添加用户和设定权限的并非通过网页程序，而只是管理一个特殊的 Git 仓库。你只需要在这个特殊仓库内做好相应的设定，然后推送到服务器上，Gitosis 就会随之改变运行策略，听起来就很酷，对吧？ Gitosis 的安装算不上傻瓜化，但也不算太难。用 Linux 服务器架设起来最简单 — 以下例子中，我们使用装有 Ubuntu 8.10 系统的服务器。 Gitosis 的工作依赖于某些 Python 工具，所以首先要安装 Python 的 setuptools 包，在 Ubuntu 上称为 python-setuptools： $ apt-get install python-setuptools 接下来，从 Gitosis 项目主页克隆并安装： $ git clone git://eagain.net/gitosis.git $ cd gitosis

初步了解 IntelliJ IDEA v13应用服务器 以后，接下来我们将继续设置应用服务器的运行配置。 Artifacts是IDE在通过运行配置时部署的一个服务。Artifacts包括名称、类型、输出目录、布局和设计。Artifacts设置在Project Structure丨Artifacts 如果使用的是Maven或Gradle，不需要手动配置工作。因为IntelliJ IDEA v13将自动同步构建文件。 运行配置部署到服务器有2中方式：本地和远程 每个应用服务器可能拥有不同的运行配置参数： 这些重要的参数，涉及到应用程序的更新，如：资源更新，重新部署和重启服务器等。 其中frame deactivation参数是非常重要的，设置这个参数，可以在不去更新资源和部署的情况下，在使用浏览器时自动更新。 值得注意的是远程运行配置需要额外的添加 主机 和 端口 。 欢迎大家下载 IntelliJ IDEA v13试用版 来开发和部署应用程序。 来源： oschina 链接： https://my.oschina.net/u/1251054/blog/195451

到目前为止，你应该已经学会了使用 Git 来完成日常工作。然而，如果想与他人合作，还需要一个远程的 Git 仓库。尽管技术上可以从个人的仓库里推送和拉取修改内容，但我们不鼓励这样做，因为一不留心就很容易弄混其他人的进度。另外，你也一定希望合作者们即使在 自己不开机的时候也能从仓库获取数据 — 拥有一个更稳定的公共仓库十分有用。因此，更好的合作方式是建立一个大家都可以访问的共享仓库，从那里推送和拉取数据。我们将把这个仓库称为 “Git 服务器”；代理一个 Git 仓库只需要花费很少的资源，几乎从不需要整个服务器来支持它的运行。 架设一台 Git 服务器并不难。第一步是选择与服务器通讯的协议。本章第一节将介绍可用的协议以及各自优缺点。下面一节将介绍一些针对各个协议典型的设置以及如何在服务器 上实施。最后，如果你不介意在他人服务器上保存你的代码，又想免去自己架设和维护服务器的麻烦，倒可以试试我们介绍的几个仓库托管服务。 如果你对架设自己的服务器没兴趣，可以跳到本章最后一节去看看如何申请一个代码托管服务的账户然后继续下一章，我们会在那里讨论分布式源码控制环境的林林总总。 远程仓库通常只是一个_裸仓库（bare repository）_ — 即一个没有当前工作目录的仓库。因为该仓库只是一个合作媒介，所以不需要从硬盘上取出最新版本的快照；仓库里存放的仅仅是 Git 的数据。简单地说

Supervisor 是由 Python 语言编写、基于 linux 操作系统的一款服务器管理工具，用于监控服务器的运行，发现问题能立即自动预警及自动重启等。 Cloud Insight 是一款次世代监控工具兼数据管理平台。使用 StatsD 采集性能指标，在 HBase 存储之上，使用 OpenTSDB 来对性能指标进行聚合、分组、过滤。 ##使用 Supervisor 的原因 如果你有很多进程在跑，不时还需要 start/stop/restart 一下进程 如果哪天由于某种原因，进程挂了，你需要重启进程或定时执行脚本 如果有多个进程，有些是同一项目，尽量可以同时启动/停止等 如果你有以上任意一种情况，那用 Supervisor 管理进程无疑再合适不过了，把你所有 *nix 进程都配置进 ini 文件中，这样所有的进程就变成了 Supervisor 的子进程。对于子进程，Supervisor 可以做到准确管理（有 web 界面），可以进行分组，一组组的 或者授权非 root 用户。 ##Supervisor 管理进程， Cloud Insight 监控进程 Supervisor 只能管理进程，对进程进行操作，但不能监控进程，虽然有 web 界面可以显示/管理的进程，但不具备一般意义上的监控。例如实时展示进程数据，出现问题有相应报警邮件。 Cloud Insight 可以监控

尝试自己写 Blog 的人，一般会经历三个阶段。 第一阶段，刚接触 Blog，觉得很新鲜，试着选择一个免费空间来写。 第二阶段，发现免费空间限制太多，就自己购买域名和空间，搭建独立博客。 第三阶段，觉得独立博客的管理太麻烦，最好在保留控制权的前提下，让别人来管，自己只负责写文章。 大多数人，都停留在第一和第二阶段，因为第三阶段不太容易到达：你很难找到俯首听命、愿意为你管理服务器的人。 前两天在站长之家里面看到一个文章，讲的是如何在 github 上搭建 Blog，现在分享给大家。比较详细的介绍了 github 的 Pages 功能，以及 Jekyll 软件的基本用法。 从大概 2012 年开始，一些程序员开始在 Github 网站上搭建 blog，既拥有绝对管理权，又享受 github 带来的便利：不管何时何地，只要向主机提交 commit，就能发布新文章，还是免费的！github 提供无限流量，世界各地都有理想的访问速度。 #####一、Github Pages 是什么？ 如果你对编程有所了解，就一定听说过 github,它号称程序员的 Facebook，有着极高的人气，许多重要的项目都托管在上面。 简单说，它是一个具有版本管理功能的代码仓库，每个项目都有一个主页，列出项目的源文件。 但是对于一个新手来说，看到一大堆源码，只会让人头晕脑涨，不知何处入手。他希望看到的是

IntelliJ IDEA v13应用out-of-the-box支持众多企业级和开源的服务器，包括：GlassFish、WebLogic、 JBoss EAP、Wildfly、WebSphere、Tomcat、TomEE、Jetty、 Geronimo、Resin和Virgo。 在 Settings丨Application Servers 点击添加应用程序服务器，IntelliJ IDEA会自动检查版本，根据依赖关系来确定应该选择的资源库。 在web方面，IntelliJ IDEA通过项目结构模块来确定web资源。通过如下模块设置： IntelliJ IDEA v13最新支持——在线支持更新应用程序服务器。 对于IntelliJ IDEA v13的应用服务器，慧都会持续关注其工作部署，运行配置等。 下载IntelliJ IDEA v13试用版 来源： oschina 链接： https://my.oschina.net/u/1251054/blog/195447

一．软件介绍 (apache lighttpd nginx) 1. lighttpd Lighttpd是一个具有非常低的内存开销，cpu占用率低，效能好，以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。 Lighttpd使用fastcgi方式运行php,它会使用很少的PHP进程响应很大的并发量。 Fastcgi的优点在于： · 从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑. · 从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮, · 从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1) · 从扩展性上讲, fastcgi是一个中立的技术标准, 完全可以支持任何语言写的处理程序(php,java,python...) 2. apache

工作中主要使用C/C++作为开发语言。 也曾在PHP,JAVA,JS, LUA 上逗留过，但对它们，我没有花费过多的精力。部分原因可能是由于工作不能实际使用这些语言来开发项目，而我的理解是它们对我的吸引力还不够。 但是，当我偶遇上了Erlang，一见如故人，竟然能完全满足我在梦中试图用C++无数次勾勒的形象，甚至是让我惊艳的。 于是，借着Armstrong先生的《面对软件错误构建可靠的分布式系统》和《Erlang程序设计》，与这一故人已畅谈两星期有余。 Erlang为什么吸引我?现做一理性总结： 1. Erlang的动态类型，模式匹配，基于消息，面向并发的纯函数式开发范式( 由这些特性直接导出以下几点)； 2. 据说，Erlang开发效率是C/C++的9倍（待验证）； 3. 用C/C++开发服务端，我需要纠结于采用什么网络库，或是重头造轮子自己搞一套，还要对数据解包打包等等其他一些基础设施做封装，然后才能开始业务代码的编写，而Erlang把这一切都搞定了（IO能力已得到我的验证），我可以一开始就编写业务相关代码； 4. 用C++编码，我要用层层的try-catch块包裹正常的功能代码，而这样看起来总是让人厌烦，Erlang倡导的速错哲学让我完全不用关心什么地方会有未捕获的异常抛出把我的程序弄崩了； 5. 用C++,有N多个类都有Init(),Start(),Stop()

现在各种云应用的非常广，这也是今后的一个趋势。同时云安全也备受大家瞩目。前不久csdn等多家网站用户 信息被黑客获取。据悉，美国数据安全损失居全球之首 年损失960亿，这一系列无不刺激这我们的神经， 如今好像没有什么安全的方式，只有尽可能的减少漏洞和bug，才能降低因数据窃取或网络攻击带来的 损失。 在实现一种安全策略之前，首先要在理论上行的通，对系统的架构什么的必须设计的合理，然后就 要在实际操作时试着检测漏洞或bug，最好是试着攻击自己的网络，看能否达到一个抗攻击的标准。 现在存在的网络安全技术主要有： 1、防火墙技术 网络防火墙技术是一种用来加强网络之间访问控制，防止外部网络用户以非法手段通过外部网络 进入内部网络，访问内部网络资源，保护内部网络操作环境的特殊网络互联设备。防火墙位置不固定， 不同地方有各自的用途。典型的防火墙建立在一个服务器／主机机器上，亦称“堡垒”，是一个多边协议路由器，这个堡垒有两个网络联接：一边与内部网相联，另一边与Internet相联。它的主要作用除了防止未经授权的来自或对Internet的访问外，还包括为安全管理提供详细的系统活动的记录。其缺点是无法防范来自防火墙以外的攻击，不能防止内部的威胁，也不能 完全防止病毒，以及无法防范数据驱动型攻击。 2、加密技术 加密技术分为两类：对称加密和非对称加密技术。对称加密技术中