uploadify 在chrome上崩溃的办法

最近用了一下uploadify,在上传文件上还是很简单方便的。但是发现在chrome上会经常崩溃。网上找了一下解决办法,大多都是在uploadify.js后面加上一个随机时间以防止使用chrome的缓存,其实这个办法并不能完全解决崩溃问题,比如在uplodify页面进入其他页页后,再点击后退返回到这个uploadify页面,同样会出现崩溃问题。 其实如果不用缓存每次去请求服务器其实是个很浪费的事,关键是这样做根本就没有解决这个问题。真正的解决的办法也很简单,就是用setTimeout,让uplodify的初始化和浏览器缓存模块的功能不要在同时进行,操作如下: 这样即可解决启动时/后退时崩溃问题。

嵌入式linux的epoll的坑

昨天搞到一个魔豆路由器,由于这个路由器开放权限,所以手就很痒的玩了起来。 把我以前写的epoll服务器编译后上传上去,发现在接收到数据的时候程序总没反应,经过调试,发现epoll的epoll_event传的data在epoll_wait时拿到总是空,所以初步断定是内核的问题,查看内核是linux matrix 2.6.36,这个版本epoll才加入没多久,有问题应该也是可能的。 下了结论,然后再想想其实这种嵌入式设备也没必要处理大并发,所以就用select去实现了服务器,意料之中的,效果非常棒,ab测试下的benchmark在64并发10000请求条件下,比路由器上的nginx要高很多(肯定的,因为还没做http请求解析)。接下来要优化一下服务器,再把http的解析加上去。 另外,魔豆路由器的系统目录默认是只读的,要设置自己的程序开机自动执行,需要执行writesys.sh才能进行配置,配置完成后再使用writesys.sh close 把目录改回只读。

mac上挂载sftp到文件系统中

mac的finder不像ubuntu的natuilus那样可以直接挂载sftp,对于需要经常编辑sftp目录上的文件来说很不方便,所以研究了下挂载方法。 发现github上有一个开源的软件是sshfs,该软件可以以命令行的方式将远程sftp挂载到mac的文件系统中,从而实现简单的修改。项目地址: http://osxfuse.github.io/ 需要安装 sshfs和osxfuse

开发验证码时需要注意的问题 — 为什么总有些人验证码输得很快?

验证码的出现是为了防止电脑程序模拟人工操作,实现批量,快速的数据请求. 一般验证码按以下流程开发: 1. 表单页面请求验证码图片生成程序 2. 验证码生成程序随机生成一个验证码,保存到服务器session中,并将验证码按一定随机规则画到一张图片上,返回给页面 3. 如果用户看不清,请求换一张,跳到步骤1,如果用户看得清,输入验证码,提交表单,跳到步骤4 4. 表单处理程序判断用户输入的内容跟session中保存的验证码是否一致,如果一致,通过数据提交,如果不一致,回到步骤1,要求重新填写. 看似简单的几个步骤,实现时却要注意以下两个问题: 1.验证码自动识别问题 这个是最容易想到的问题,机器通过图像识别,仍然可以得到验证码内容.一般验证码识别通过将图片二值化,降噪后,再进行特征提取,根据特征来对应具体的字符,所以简单的验证码操作根本就难不到计算机,以至于现在好多的验证码加了很多扭曲和添加杂色杂线的工作,甚至用了汉字来增加难度.只有这样做才会有效果. 对于机器识别的防治,最好是走正统方式,建议不要自己随便想一种机制就拿来应用,有可能我们想到的办法别人一下子就找到了很简单的识别方式.记得以前我就遇到一个游戏的验证码,是点击图片中只出现过一次的物品的区域,其他物品都出现过多次,感觉好像很难破的样子,其实只要把图片中的颜色进行分组,出现次数最少的那一组所在的区域就是需要点击的区域… 防制机器识别,还有一种办法是多做几套识别码,关键时刻换着用.对于像12306这样的网站非常合适,比如一年内做个10套验证码,平时用第一套,春运的时候换着用其他9套,让刷票软件花好多心思做出来的识别程序最终毫无用处. 2.验证码刷新时间问题 这个是很容易忽视的问题,特别在做抢有限资源的功能的验证码时要注意.比如12306的抢票或淘宝的抢购功能的验证码.操作方式就是提前通过验证码的链接获得验证码图片,并把验证码准备好(例如打好后复制起来),当开抢时,不加载新的验证码图片,直接提交开抢之前准备好的验证码,如果程序没有注意到时间问题,就会认为该验证码有效,从而达到”快速输入验证码”的效果. 对于这种情况,生成验证码保存session的时候,可以多保存一个刷新时间,当用户提交验证时,判断如果这个验证码是在开抢之前生成的,则此次验证结果无效. 当然,验证码也有一种无法防止的问题,那就是人工打码.这个也是好多年前就在游戏行业出现的服务,软件通过将验证码传输到打码团队某个成员的电脑上,由打码人员输入验证码并回传,程序再自动将验证码输入,这种方式往住有一定的利益关系才能维持下来,所以开发人员也不用太过担心这个问题.

爽,java servlet 3 实现了异步处理机制

servlet 3是servlet的升级,tomcat在第7版本以后实现了该标准,最主要的特性就是加入了请求异步处理的功能。 异步是网络中最常用最高效的处理模型,通过异步,就可以实现让当前请求先保持连接,让cpu去处理其他的请求,当满足某个条件时再回来处理这个连接。 有了异步功能,我们的服务器就可以实现如下的一些功能: 1. long-polling长轮询 2. websocket等持久连接 异步主要通过Servlet的startAsync完成,这个函数返回AsyncContext,可以通过对AsyncContext设置超时和事件监听。如果超时没有处理,连接就会自动断开并调用事件监听器的onTimeout,程序可以在onTimeout中进行处理,如果调用了AsyncContext的complete,连接则会正常关闭,否则会抛错。 AsyncListener包含如下函数: void onComplete(AsyncEvent event); //当异步处理完成时调用 void onError(AsyncEvent event); //当出错时调用,比如超时了但没有调用complete void onStartAsync(AsyncEvent event); //当开始进入异步状态时调用,即调用startAsync时 void onTimeout(AsyncEvent event); //当超时的时候调用 其中要注意的是onStartAsync,由于AsyncContext是在ServletRequest的startSync后才能获取到,获取后才能添加listener,所以第一次的onStartAsync是不会被调用到的,但由于ServletRequest的startSync可以多次调用,所以当下次startSync时,onStartAsync才会被调用到。 最后要注意的的是servlet需要标记async=true @WebServlet(asyncSupported = true) 并在startAsync之前添加如下设置 request.setAttribute(“org.apache.catalina.ASYNC_SUPPORTED”, true);

mac os上使用sftp传输文件

ssh确实是很不错的东西,不仅可以控制计算机、打隧道,还可以进行安全的文件传输。 mac上的finder好像并不支持sftp协议,所以需要使用命令行的方式进行文件传输,传输方式也很简单: 1. 连接目标服务器: 使用 sftp user@host 的方式连接上目标服务器,认证成功后,会出现sftp交互模式 2. 输入相关命令,即可进行sftp交互,这些命令包括: pwd            打印服务器当前目录 lpwd 打印本机当前目录 cd 切换服务器当前目录 lcd 切换本机当前目录 ls 列出服务器当前目录下的文件 lls 列出本机当前目录下的文件 mkdir 为服务器创建目录 lmkdir 为本机创建目录 get 取得远程服务器上的指定文件 put 上传本地指定的文件到远程服务器上 help 取得帮助