运行程序显示“从服务器返回一个参照”怎么办

　　方法一、

　　1、以管理员身份运行，出现“从服务器返回一个参照”是因为可执行文件没有权限导致的，所以给予它最高权限，这样就可以解决问题了。

如何解决win7运行程序时显示“从服务器返回一个参照” 三联

　　2、如果你经常使用这个软件的话，可以配置打开方式，比较方便，这样它就可以每次打开的方式都是以管理员身份运行了，方法是鼠标右击执行文件，然后选择“属性”，在“兼容性”选项卡中，然后在特权等级下勾选“以管理员身份运行此程序”，点击确定退出即可。

　　方法二、

　　1、打开开始菜单中的控制面板，然后点击控制面板中用户账户界面下方的“更改用户账户控制设置”;

“更改用户账户控制设置”

　　2、接着在打开的控制设置面板中，将下方的按钮滑动至“从不通知”即可。

按钮滑动至“从不通知”

　　方法三、

　　1首先打开运行对话框，并输入“gpeditmsc”，回车打开组策略;

输入“gpeditmsc”

　　2然后在打开的组策略窗口中依次展开“计算机配置-windows配置-安全配置”选项;

展开“计算机配置-windows配置-安全配置”选项

　　3、然后在窗口右侧中找到并双击“用户账户控制：值提升签名并验证的可执行文件”选项，选择禁用即可。

双击“用户账户控制：值提升签名并验证的可执行文件”选项

截取一段时间内的log日志可以使用sed命令对log文件进行抽取操作:

1，sed查看某时间段到现在的系统日志：

sed -n '/May 20 17/,$p' /var/log/messages | less

2，sed 截选时间段日志：

假如日志的格式是--

“2015-05-04 09:25:55,606 后面跟日志内容 ”这样的

目标是需要将05-04的09:25:55 和09:28:08 之间的日志截取出来：

使用sed命令如下：

sed -n ‘/2015-05-04 09:25:55/,/2015-05-04 09:28:55/p’ logfile

这样可以精确地截取出来某个时间段的日志。

如果需要截取的日志太大，达到几个G的话，不能去vi打开文件:

根据之前的日志格式，使用正则表达式:

sed -n ‘/2011-11-17 09:[0-9][0-9]:[0-9][0-9]/,/2011-11-17 16:[0-9][0-9]:[0-9][0-9]/p’ logfile

如果没有问题的话，上面就能筛选出指定的时间段的日志。

1、进入一个服务器，我这里进的是国服的花雨庭服务器。一般主城都会有介绍，新手教程等等。在的工具栏里一般有一本书，可以右键打开。

2、接下来进入一个生存服，右击工具栏下面的钟，然后点击左上角的新手指南的书，找到圈地教程：每个服务器可能不一样，但都大同小异，有的使用木斧头，有的用木棍。这个服务器用的是木棍。方法是“/res create 领地名”。

3、一般玩我的世界大家在输入文字时最好切换到英文输入法，因为要输入“/”这个符号，和其他玩家聊天也是用“/”打开的。圈地是需要钱（游戏里的钱），一般游戏里都可以赚钱，挖矿，卖农作物等等。

4、然后进入游戏，在地上放个方块（任何方块都可以），拿木棍左键点击一下。然后沿着这个方块的对角线过来到需要的大小（需要多大就圈多大只要有钱），往上垒方块到我们需要的高度，然后拿木棍右击（注意这里是右击，刚才第一次木棍是左击），这个过程不要乱跑，要站在刚才圈的范围内然后输入/res create mc0078。注意mc0078可以换成喜欢的名字。这样就成功创建一个领地了。

5、下面我们来扩大的领地。输入/res，然后回车可以看到左下角有很多领地设置，添加玩家，权限等等。点击下一页找到扩大领地的方法。可以看到是expand（“中文是扩大的意思”）。

6、然后把鼠标放到上面就可以查看这个命令的使用方法了。

7、世界服务器怎么圈地建领地，扩大自己的领地

8、要站在领地里面，外面是无效的。然后面朝一个方向输入/res expand mc0078 2，回车就可以了。的

在平时的开发中，经常会碰到一些需要检测tcp连接是否正常的场景。比如一个分布式的应用，一个调度任务的节点管理一堆用来跑业务的节点。当调度节点进行调度的时候，需要把任务分发给它认为正常的业务节点去执行。业务节点是否正常，一个重要的参考依据就是调度节点和业务节点之间的tcp连接是否正常。这时候就需要调度节点主动地去检测tcp连接。常见的检测方法有以下几种

方案一、通过TCP协议的返回值进行判断

　　　　<1> 利用select，把socket设置为非阻塞。然后使用select等待该socket的可读事件。如果socket可读，但是recv的返回值是0，则说明socket已经被对端断开，这时候就可以调用close关闭socket。这里还要注意一点，recv还可能返回负数，这个代表socket操作出错。但是仍然应该判断一下errno是否为EINTR。如果errno是EINTR，则说明recv函数是被信号中断返回的，这时候不能判断socket的连接是否正常，也不应该调用close关闭socket。

　　　　<2> 利用poll的事件。poll本身提供了POLLHUP，POLLERR, POLLNVAL三个事件。如果文件描述符是socket，则POLLHUP代表socket已经断开了连接，在TCP底层就是已经收到了FIN报文。POLLERR表示socket出现了错误，一般情况下是收到了rst报文，或者已经发送了rst报文。这两种情况都应该调用close关闭socket。POLLNVAL代表socket没有打开，这时不能使用close关闭它，而应该根据自己的业务做一些其他的操作。因为关闭一个未打开的socket会出错。

　　　　这两种方法都可以很精确地判断tcp连接是否正常，但是仍然有很明显的缺陷。就是它只可以根据TCP操作的返回值来进行判断。如果TCP四次握手没有正常被执行呢？比如连接对端机器直接挂了，那么就不会发送FIN报文给这一端，select不会返回socket可读，poll不会返回socket异常。那么这个死链接将会永远检测不到。直到写这个socket的时候，对端直接返回一个ret报文，这时才知道这个连接已经断掉了。这就意味着tcp连接异常可能永远检测不到，或者检测到的延迟非常大。这对于一些资源宝贵而且要求高性能的服务器是不能接受的，比如游戏服务器，比如搜索服务器。

方案二、在第一种方案的基础上设置socket的 keep alive 机制

　　　　方案一的主要缺陷在于检测不及时，或者根本检测不到。TCP协议提供了keep alive机制。如果开启了这个特性（暂时称开启了keep alive的一端为开启端），在默认情况下，开启的着一端的socket相关结构中会维护一个定时器，默认是2小时。如果在2小时内两端没有数据往来，那么开启端就会给另一端发送一个ack空报文。这时候分几种情况：

　　　　<1> 对端机器可达，而且TCP相关组件运行正常。那么对端就会给开启端发送一个ack空报文。这时开启端就知道对端是正常的，意味着tcp连接也没有问题。开启端会重新初始化定时器，等待下一个超时的到来。需要注意的是，如果两端之间有数据往来，定时器也会被重新初始化为2个小时。　　

　　　　<2> 对端挂了，或者正在重启，还没有完全起来。或者对端服务器不可达。 这种状态的对端是不会响应这个ack的。开启端的 keep alive 机制会把这种情况当探测超时来处理，并且重新发送ack到对端。当超时次数超过一定限制，keep alive 就认为这个tcp连接有问题。典型值是每次75秒，超时9次。

　　　　<3> 对端挂过，但是已经重启完成。这时候发送这个ack和写已经关闭的socket是一种情况，对端会返回一个rst报文，这样开启端就知道tcp连接出问题了。

　　　　可以看出 keep alive 机制弥补了方案一种不能判断没有进行正常四次挥手连接出现问题的缺陷。默认的发送超时和发送间隔都是可以调整的。　　　　

　　　　tcp_keepalive_time: KeepAlive的空闲时长，默认是2小时

　　　　tcp_keepalive_intvl: KeepAlive探测包的发送间隔，默认是75s　

　　　　tcp_keepalive_probes: 在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包次数，默认是9次

　　　　这3个参数使用 setsockopt函数都是可以配置的。

　　　　方案二看似已经完美了，能够比较精确而且及时地发现有问题的连接。但是还有2个缺点。第一个是 keep alive 机制看似牛逼，但是很多人不建议使用。因为上面说的3个参数很难根据业务场景给出合适的值，设置不好很容易对tcp连接状态发生误判，关闭了一个本来正常的连接。而且没有一个主动通知应用层的方式。比如socket连接出错了，TCP协议接到了rst，fin，或者keep alive判断出socket有问题了，但是并不会主动去通知应用层，必须我们自己 recv socket或者等待错误事件才能得到这个错误。第二个是很多场景下，keep alive 检测仍然不够及时，比如对端挂了，最长需要等待 tcp_keepalive_intvl tcp_keepalive_probes时间才可以检测出来，而且这两个值还不能设置得太小，太小了容易误判。

方案三、应用层的心跳

　　　　这种形式的心跳设计就比较多样化了，而且灵活，可以很好地适应业务场景。唯一的缺点就是要自己写代码。我目前接触到的就是定期进行RPC调用。看RPC调用是否正常，如果返回错误或者抛出异常，就说明连接有问题。