Determining IP information for eth0…failed

如果安装的时候选择了默认的网络配置,那么eth0应该是DHCP分配地址,建议不用管它,进入系统后手动配置: ifconfig   eth0   192.100.110.1   netmask   255.255.255.0   up 这里的ip和子网掩码替换成你自己的 在windows 网络邻居上的VMware网卡的ip段内,只要设置ip属于两个网卡的网段中的一个就可以 获取地址失败,你应该配置的是自动获得地址,如果没有DHCP服务器为你分配地址,自然就会失败。自己手工配置一下地址就可以了, 执行命令: ifconfig eth0 你的IP地址 linux Radhat Enterprise 5.3  敲命令设置IP地址时出现:  >>ifconfig eth0  172.16.5.143 netmask 255.255.255.0 >>/etc/init.d/nfs restart  Shutting down interface eth0:                              [  OK  ] Shutting down loopback interface:                          [  OK  ] Bringing up loopback interface:                            [  OK  ] Bringing up interface eth0:   Determining IP information for eth0… failed.             [FAILED] 半天找不出问题。只好直接修改配置文件: /etc/sysconfig/network-scripts/ifcfg-eth0  DEVICE=eth0 ONBOOT=yes BOOTPROTO=none             //原来为 hdcp HWADDR=00:0c:29:2b:c7:e5 BROADCAST=172.16.5.255 IPADDR=172.16.5.142 NETMASK=255.255.255.0 NETWORK=172.16.5.0 […]

自反+递归 实现评论的无限引用

引言 大家每天都在看博客,发表评论,实现一个评论系统也是一名Web开发者的基本要求。虽然评论只是一个很普通的功能,但是实现评论的引用,尤其是无限引用,却有一定的困难。身为“网易工程队”的正规军,同时又作为一名程序开发人员,有必要向大家展示一下“盖楼”的方法。 效果预览:http://www.tracefact.net/demo/NestedComment/Default.aspx NOTE:本文使用 基于业务对象(List<Comment>)的筛选 来进行引用列表的搜寻,对数据库仅进行了一次读取。想也应该能想明白:不管是初始评论还是包含引用的评论都属于同一文章下,一次读取该文章下的评论,进行 列表搜寻就可以了,为什么要多次读取数据库!? 尽管如此,使用递归的效率依然是很低的,会进行频繁的方法调用,所以这篇文章的方法基本上只有实验价值,没有使用价值。可以考虑在Comment表中建一个字段,QuoteContent,用来保存引用的内容,QuoteContent可以使用文中的方法来获得。 评论引用的“传统方法” 称之为“传统方法”,是因为这种方法很多的论坛都在采用,比如说 蓝色理想。做法是在点引用的时候,在回帖人的正文中,加入代码比如“[quote]引用内容…[/quote]回复正文”,然后在输出的时候,将UBB代码用正则表达式替换成HTML代码。 这种方法的好处是取出数据速度比较快,直接从数据库读出再送显就可以了。缺点是写正则表达式比较麻烦,而且容易出错,比如一个[quote]的嵌套位置不正确,就会使表达式失效;还有就是会让数据库存储额外的数据(引用的内容也存储了)。 这种方法很多人可能都用过,我们就不讨论了,直接进入我们的正题。 自反关系的表结构 我们先介绍一下本文会频繁用到的两个术语: 初始评论:表示这个评论没有引用其他任何评论。 引用评论:表示这个评论包含对其他评论的引用。 数据表的结构是实现无限引用的前提,设计的不好就会很难实现。我们先看一下建表的脚本: Create Table Comment ( Id         int identity(1,1)     Not Null, UserName   Varchar(200)          Not Null, Content    Varchar(2000)         Not Null, PostDate   DateTime              Not Null Default GetDate(), CommentId  Int                   Null,      — 外键,自反关系 ArticleId  Int                   Not Null Constraint pk_Comment Primary […]

使用 libevent 和 libev 提高网络应用性能

简介: 构建现代的服务器应用程序需要以某种方法同时接收数百、数千甚至数万个事件,无论它们是内部请求还是网络连接,都要有效地处理它们的操作。有许多解决方案,但是 libevent 库和 libev 库能够大大提高性能和事件处理能力。在本文中,我们要讨论在 UNIX® 应用程序中使用和部署这些解决方案所用的基本结构和方法。libev 和 libevent 都可以在高性能应用程序中使用,包括部署在 IBM Cloud 或 Amazon EC2 环境中的应用程序,这些应用程序需要支持大量并发客户端或操作。   简介 许多服务器部署(尤其是 web 服务器部署)面对的最大问题之一是必须能够处理大量连接。无论是通过构建基于云的服务来处理网络通信流,还是把应用程序分布在 IBM Amazon EC 实例上,还是为网站提供高性能组件,都需要能够处理大量并发连接。 一个好例子是,web 应用程序最近越来越动态了,尤其是使用 AJAX 技术的应用程序。如果要部署的系统允许数千客户端直接在网页中更新信息,比如提供事件或问题实时监视的系统,那么提供信息的速度就非常重要了。在网格或云环境中,可能有来自数千客户端的持久连接同时打开着,必须能够处理每个客户端的请求并做出响应。 在讨论 libevent 和 libev 如何处理多个网络连接之前,我们先简要回顾一下处理这类连接的传统解决方案。 处理多个客户端 处理多个连接有许多不同的传统方法,但是在处理大量连接时它们往往会产生问题,因为它们使用的内存或 CPU 太多,或者达到了某个操作系统限制。 使用的主要方法如下: 循环:早期系统使用简单的循环选择解决方案,即循环遍历打开的网络连接的列表,判断是否有要读取的数据。这种方法既缓慢(尤其是随着连接数量增加越来越慢),又低效(因为在处理当前连接时其他连接可能正在发送请求并等待响应)。在系统循环遍历每个连接时,其他连接不得不等待。如果有 100 个连接,其中只有一个有数据,那么仍然必须处理其他 99 个连接,才能轮到真正需要处理的连接。 poll、epoll 和变体:这是对循环方法的改进,它用一个结构保存要监视的每个连接的数组,当在网络套接字上发现数据时,通过回调机制调用处理函数。poll 的问题是这个结构会非常大,在列表中添加新的网络连接时,修改结构会增加负载并影响性能。 选择:select() 函数调用使用一个静态结构,它事先被硬编码为相当小的数量(1024 个连接),因此不适用于非常大的部署。 在各种平台上还有其他实现(比如 Solaris 上的 /dev/poll […]