accept

input type=file类型限定选择文件的类型

旧巷老猫 提交于 2020-04-27 22:22:43
HTML5中可以使用input的accept可以限定上传文件的类型 例如使用 accept 属性(允许上传两种文件类型:gif 和 jpeg) <input type="file" name="pic" accept="image/gif,image.jpg"/> accept 属性仅适用于 <input type="file">,它规定了可通过文件上传提交的文件类型。 拓展 accept可以指定如下信息 *.3gpp audio/3gpp, video/3gpp 3GPP Audio/Video *.ac3 audio/ac3 AC3 Audio *.asf allpication/vnd.ms-asf Advanced Streaming Format *.au audio/basic AU Audio *.css text/css Cascading Style Sheets *.csv text/csv Comma Separated Values *.doc application/msword MS Word Document *.dot application/msword MS Word Template *.dtd application/xml-dtd Document Type Definition *.dwg image/vnd.dwg AutoCAD

socket的accept函数解析

妖精的绣舞 提交于 2020-04-11 23:32:46
今天与同学争执一个话题: 由于socket的accept函数在有客户端连接的时候产生了新的socket用于服务该客户端,那么,这个新的socket到底有没有占用一个新的端口? 讨论完后,才发现,自己虽然熟悉socket的编程套路,但是却并不是那么清楚socket的原理,今天就趁这个机会,把有关socket编程的几个疑问给搞清楚吧。 先给出一个典型的TCP/IP通信示意图。 问题一:socket结构体对象究竟是怎样定义的? 我们知道,在使用socket编程之前,需要调用socket函数创建一个socket对象,该函数返回该socket对象的描述符。 函数原型:int socket(int domain, int type, int protocol); 那么, 这个socket对象究竟是怎么定义的呢?它记录了哪些信息呢?只记录了本机IP及端口、还是目的IP及端口、或者都记录了? 关于这个问题,大家可以在内核源码里面找,也可以参考这篇文章《struct socket 结构详解》,我们可以看到 socket 结构体的定义如下: struct socket { socket_state state; unsigned long flags; const struct proto_ops *ops; struct fasync_struct *fasync_list; struct file

ACE的Socket

橙三吉。 提交于 2020-04-06 17:16:49
转自:http://www.rosoo.net/a/cpp/2010/0127/8416.html 使用ACE进行Socket编程,需要使用到下面几个类: ACE_SOCK_Connector :连接器,主动建立连接,用于Socket Client; ACE_SOCK_Acceptor :接受器,被动建立连接,用于Socket Server; ACE_SOCK_Stream :传输数据的流,用于传输数据; ACE_INET_Addr :用于表示通信端点的地址; ace/INET_Addr.h文件中定义了一些有用的ACE_INET_Addr构造函数,用于创建通信端点的地址;一旦构造好一个通信端点的ACE_INET_Addr信息,那么,就可以使用这个地址去连接服务器了;ACE中使用ACE_SOCK_Stream类的对象来表示已经连接成功的TCP Socket;之所以这样命名,是因为TCP连接代表的是面向连接的虚连接,或者是"字节流"; 短写问题 :当你试图把一些字节写往远程主机时,由于网络缓冲区溢出、拥塞,或其它任何原因,导致你的字节没有被全部送出去,那么随后,你必须移动你的数据指针,发送剩余的数据;你必须持续地做这样的发送操作,直到把原来所有的自己全部都发送出去为;止.这样的问题在网络编程中发生的非常频繁,ACE的send_n()方法调用封装了这些操作

部署项目使用的redis

大兔子大兔子 提交于 2020-04-05 16:59:02
系统centos 6 redis 5 在官网下载并拷贝到/opt文件中 把tar.gz压缩包解压到当前文件夹下 安装需要的依赖 yum -y install gcc automake autoconf libtool make cd redis-5.0.8 make cd src make install PREFIX=/usr/local/redis 安装完 配置redis.conf 文件 vim /opt/reids-5.0.8/redis.conf 1.配置bind 把静态地址绑定到 bind中,默认为127.0.0.1本机,需要改成本机静态地址或者注释掉 2.配置daemonize设为yes,把redis运行改为以守护进程模式运行 3.配置protected-mode为no,不知道是否有用,防止远程访问不了redis redis配置完,:wq,配置防火墙iptables 放行6379端口 网上很多都只说了加入一个规则,就是在chain input里面加入端口6379 -p tcp下的accept 但是这里需要注意的是,防火墙的这条规则必选写在可以被chain放行的位置,因为iptables不熟悉,所以这花了10多小时才找到加入了放行6379端口的规则但是依然远程访问不到这个端口的原因 :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0]

设计模式之访问者模式(Visitor)详解及代码示例

一曲冷凌霜 提交于 2020-04-02 06:06:25
一、访问者模式的定义与特点   访问者(Visitor)模式的定义:将作用于某种数据结构中的各元素的操作分离出来封装成独立的类,使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作,为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离,是行为类模式中最复杂的一种模式。 二、访问者模式优缺点   访问者(Visitor)模式是一种对象行为型模式,其主要优点如下: 扩展性好。能够在不修改对象结构中的元素的情况下,为对象结构中的元素添加新的功能。 复用性好。可以通过访问者来定义整个对象结构通用的功能,从而提高系统的复用程度。 灵活性好。访问者模式将数据结构与作用于结构上的操作解耦,使得操作集合可相对自由地演化而不影响系统的数据结构。 符合单一职责原则。访问者模式把相关的行为封装在一起,构成一个访问者,使每一个访问者的功能都比较单一。   访问者(Visitor)模式的主要缺点如下: 增加新的元素类很困难。在访问者模式中,每增加一个新的元素类,都要在每一个具体访问者类中增加相应的具体操作,这违背了“开闭原则”。 破坏封装。访问者模式中具体元素对访问者公布细节,这破坏了对象的封装性。 违反了依赖倒置原则。访问者模式依赖了具体类,而没有依赖抽象类。 三、访问者模式的实现   访问者(Visitor)模式实现的关键是如何将作用于元素的操作分离出来封装成独立的类

CentOS 6.2 yum安装配置lnmp服务器(Nginx+PHP+MySQL)

孤街浪徒 提交于 2020-03-31 04:39:39
准备篇: 1、配置防火墙,开启80端口、3306端口 vi /etc/sysconfig/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT(允许80端口通过防火墙) -A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT(允许3306端口通过防火墙) 特别提示:很多网友把这两条规则添加到防火墙配置的最后一行,导致防火墙启动失败,正确的应该是添加到默认的22端口这条规则的下面 添加好之后防火墙规则如下所示: ######################################################### # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A

socket通信原理

China☆狼群 提交于 2020-03-26 16:50:35
1、什么是socket 我们知道进程通信的方法有管道、命名管道、信号、消息队列、共享内存、信号量,这些方法都要求通信的两个进程位于同一个主机。但是如果通信双方不在同一个主机又该如何进行通信呢?在计算机网络中我们就学过了tcp/ip协议族,其实使用tcp/ip协议族就能达到我们想要的效果,如下图(图片来源于《tcp/ip协议详解卷一》第一章1.3)           、                            图一 各协议所处层次 当然,这样做固然是可以的,但是,当我们使用不同的协议进行通信时就得使用不同的接口,还得处理不同协议的各种细节,这就增加了开发的难度,软件也不易于扩展。于是UNIX BSD就发明了socket这种东西,socket屏蔽了各个协议的通信细节,使得程序员无需关注协议本身,直接使用socket提供的接口来进行互联的不同主机间的进程的通信。这就好比操作系统给我们提供了使用底层硬件功能的系统调用,通过系统调用我们可以方便的使用磁盘(文件操作),使用内存,而无需自己去进行磁盘读写,内存管理。socket其实也是一样的东西,就是提供了tcp/ip协议的抽象,对外提供了一套接口,同过这个接口就可以统一、方便的使用tcp/ip协议的功能了。百说不如一图,看下面这个图就能明白了。                                         

网络编程之socket新解

这一生的挚爱 提交于 2020-03-25 03:49:31
   由于工作并不是很忙,闲暇之余就读了下tomcat的源代码。我是从事java服务器开发工作的,大体的一些服务器线程模型我都是了解的。其大部分都是由一个线程调用监听端口等待客户端的链接,建立连接后再交由其他的线程负责具体的网络io操作。可tomcat居然是用多个线程调用同一个ServerSocket实例的accept方法。我读过mina也读过netty的源码,自己在大学时也写过不少的基于socket通信的程序,但是这种用法自己从未想过也从未见过。(恕本人咕噜寡闻了,-_-|||)不免好奇,这么做原来没问题啊?可这么做能有什么好处吗?   要明白这么做的道理,恐怖不得不去搞清楚套接字的accept方法底层到底干了什么,与TCP的三步握手又是什么关系。我查了一些资料大体把这些搞明白了,在这里记录下来以加强自己的认识,也同时共享给哪些跟我一样对socket的认识有所偏差的人。   一、首先说一下TCP三步握手的基本流程,如下图:   首先,请求端(客户端)发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;   第二步,服务器在收到客户端的SYN报文后,进入SYN-RECEVIED状态并将这个还没有完全建立起的连接放到半连接队列。还要返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一

iptables配置记录

青春壹個敷衍的年華 提交于 2020-03-24 11:58:34
一个小时内同一IP请求连接次数超过5次,封IP 1个小时。 同时,限制发起请求的IP段 # cat /etc/sysconfig/iptables # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT #-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -N Recent_Block -A Recent_Block -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --rcheck --seconds 3600 --hitcount 5 -j DROP -A Recent_Block -p tcp -

Nginx中accept锁的机制与实现

纵然是瞬间 提交于 2020-03-24 02:07:33
前言   nginx采用多进程的模,当一个请求过来的时候,系统会对进程进行加锁操作,保证只有一个进程来接受请求。   本文基于Nginx 0.8.55源代码,并基于epoll机制分析   1. accept锁的实现   1.1 accpet锁是个什么东西   提到accept锁,就不得不提起惊群问题。   所谓惊群问题,就是指的像Nginx这种多进程的服务器,在fork后同时监听同一个端口时,如果有一个外部连接进来,会导致所有休眠的子进程被唤醒,而最终只有一个子进程能够成功处理accept事件,其他进程都会重新进入休眠中。这就导致出现了很多不必要的schedule和上下文切换,而这些开销是完全不必要的。   而在Linux内核的较新版本中,accept调用本身所引起的惊群问题已经得到了解决,但是在Nginx中,accept是交给epoll机制来处理的,epoll的accept带来的惊群问题并没有得到解决(应该是epoll_wait本身并没有区别读事件是否来自于一个Listen套接字的能力,所以所有监听这个事件的进程会被这个epoll_wait唤醒。),所以Nginx的accept惊群问题仍然需要定制一个自己的解决方案。   accept锁就是nginx的解决方案,本质上这是一个跨进程的互斥锁,以这个互斥锁来保证只有一个进程具备监听accept事件的能力。