只显示主题贴

2007-10-22
全文显示

回复: 关于Erlang MagicCookie 的安全问题

mryufeng 写道cookie不是明文传送的 是cooke和node的信息 参与md5後在网络传输的 所以不用担心泄密。 http://mryufeng.javaeye.com 那我截获了某个节点发送的MD5结果以后,还是可以伪装成那个节点的. 虽然伪装IP/MAC可能有些难度,但是先通过攻击把那个节点撂倒,再伪装,也是有可能的.
2007-09-26
全文显示

回复: 疑惑：java的内存泄漏

有一个点大概可以减轻一些疑惑: GC 可能会发生在 JVM 运行期间的任何时候, 包括你的某个方法正在执行中间的某个时刻. 当然这对短小的方法来说其实没有多大差别, 但是对一些应用服务器, 框架性的代码, 有些方法是要长时间循环执行的, 甚至是跟整个应用有相同的生命周期. 在这种方法里, 尽早的null一些局部变量, 也是有防止内存泄漏的潜力的.
  • 进入论坛 Java 版
2007-09-25
全文显示

回复: 实例观察网络模型与关系模型对现实世界的建模差异

hyhongyong 写道 领域模型设计也不一定是两个动作，看螺丝和螺母哪个更主要，可以是s1.cap = c1或者c1.screw = s1吧。当然和new Screwing(s1,c1)还是有语义上的差别的。比如杯子上加个盖子，应该是 杯子1.盖子 =盖子1吧。 是的, 有的时候通过计算机解决问题并不需要自然实体的完整信息, 这些情况下网络模型就显得更为灵活, 只按需建模处理局部信息, 简单高效. 不过这些情况在数据结构, 基础算法, 有限元模拟等领域很广泛, 但是在商务计算方面就相对少见. ERP, CRM, PDM/PLM等领域关系常常还是相互的, 所以关系模型就显得更贴切些.
  • 进入论坛 Java 版
2007-09-25
全文显示

回复: 我也谈谈JAVA并发程序设计的现状和前景

目前为止的HBI实现还需要发起Domain在目标Doman环境进行Task Agent类代码的静态部署, 下一步的实现, 会利用Java, Flash等环境的动态代码部署能力, 基于密钥签名, 或者SSH线路连接的代码专用通道的方式实现动态部署. 安全性要求高的场合, Domain之间的线路连接有必要通过 SSH 的机制进行连接鉴权和通信加密, 进而某台服务器即使有非特权帐户被攻破, 也没法通过伪造或者监听本机网络通信而侵入Domain系统. 如果在这个SSH连接上增加一个专用SSH通道用来动态部署发起Domain的远程代码, 非常简单, 更安全, 且效率比HTTP, FTP等方式更高.
  • 进入论坛 Java 版
2007-09-25
全文显示

回复: 我也谈谈JAVA并发程序设计的现状和前景

一个Domain实现可以选择缓存接收到的Task Agent Life Script, 这样当发生一些有可能重试的异常时, 比如数据库乐观事务提交被强制回滚, 就可以透明的重试这个Life Script特定的次数. 数据服务性质的Domain提供这个能力尤其有用, 可以利用MVCC等乐观锁机制提高并发性能的同时简单的降低强制回滚的次数, 缓解强制事务回滚造成的用户体验损失. 如果继续深入发展, 则有可能类似于多处理器利用原子内存访问(CAS)进行同步的相同原理, 衍生出并发性高, 而且不会强制回滚的某些系统来.
  • 进入论坛 Java 版
2007-09-25
全文显示

回复: 我也谈谈JAVA并发程序设计的现状和前景

概括的说, HBI就是把分布的软件组件都设计为一个一个本地的Domain, 然后按照需要某些Domain被动接受HBI线路连接, 某些主动建立HBI线路连接, 但是原则上都是对等的, 没有服务端/客户端之分. HBI线路是对等的异步双向双工的二进制数据通道(通过Plain Socket或者HTTP包装的双向数据流实现), 也就是说两个方向上的通信没有主次之分, 不互相依赖(不用同步等待特定传输状态), 可以同时进行. 在HBI线路上传输的是 Task Agent Life Script, 具体讲就是一种二进制优化的脚本, 包括无参构造Task Agent对象, 调用构造好Task Age ...
  • 进入论坛 Java 版
2007-09-25
全文显示

我也谈谈JAVA并发程序设计的现状和前景

最近我也是在涉及并发Java方面的东西, 说说我的心得. 确实到了并发盛行的时期了, 我觉得最重要的原因还是多核处理器及其硬件体系的日趋成熟, 并且成本摊薄到大众价格了. j.u.c 包主要是为了性能来的, 其设计其实不如Java传统的内置同步机制(synchronized块和方法, 以及 Object.wait(); Object.notify())优雅, 但是传统同步机制的最大弊病就是不区分共享同步(一般是并发的读操作) 与 互斥同步 (一般是写操作), 所有同步都只能是完全排他的,只要有并发写的可能性就不得不把全部读操作也互斥同步,从而丧失并发读取的可能性. 这跟大多数应用的并发模式 ...
  • 进入论坛 Java 版
2007-09-25
全文显示

回复: 谈谈JAVA的并发程序的设计

最近我也是在涉及并发Java方面的东西, 说说我的心得. 确实到了并发盛行的时期了, 我觉得最重要的原因还是多核处理器及其硬件体系的日趋成熟, 并且成本摊薄到大众价格了. j.u.c 包主要是为了性能来的, 其设计其实不如Java传统的内置同步机制(synchronized块和方法, 以及 Object.wait(); Object.notify())优雅, 但是传统同步机制的最大弊病就是不区分共享同步(一般是并发的读操作) 与 互斥同步 (一般是写操作), 所有同步都只能是完全排他的,只要有并发写的可能性就不得不把全部读操作也互斥同步,从而丧失并发读取的可能性. 这跟大多数应用的并发模式 ...
  • 进入论坛 Java 版
2007-09-24
全文显示

回复: 初探BOSH （Bidirectional-streams Over Synchronous HTTP）

shallon 写道一条HTTP长连接在没有客户端没有发送请求的时候不断的有数据从服务器push到客户端，我不是很明白您的场景。如果push的不是一个完整的http包，而是HTTP包中的一个数据块，这是流的方式实现长连接，这种情况规范中分析了不能穿透一些proxy（有些proxy会等待完整的HTTP包再转发）。如果push的是一个完整包，这个不可能，因为客户端发送了请求给服务器端，当收到服务器端200ok的回应包时候就认为请求处理完了。客户端不会再等待其他的200ok的包（否则这个协议的请求和响应就对应不上了）。 在没有客户端没有发送请求的时候 这个没看太明白. 我设想的情况是这样: 建立这 ...
  • 进入论坛 Java 版
2007-09-24
全文显示

回复: 初探BOSH （Bidirectional-streams Over Synchronous HTTP）

服务器端HOLD住才能变成长连接呀(不然是短连接轮询啊), 这条长连接就只是downlink, 只用来接收服务器push的下行数据; 要继续发送信息, 就新开另外的短连接呀, 可以通过客户端或者服务器端的一个队列来串行化这些短连接来防止插入. 另外基于HTTP的特性, 即使是长连接, 客户端也应该只发送一次请求数据, 不该有多次roundtrip, 否则proxy/cache的通过性应该就要打折扣了.
  • 进入论坛 Java 版
歆渊
搜索本博客
存档
最新评论