| 批处理 for应用 |
作者:未知 时间:2005-09-13 21:50 出处:Blog.ChinaUnix.net 责编:chinaitpower |
| 摘要：批处理 for应用 |
for命令应用 | ||||||||
Powered by ScribeFire.
2007年11月8日星期四
批处理 for应用
2007年10月27日星期六
NetBeans 5.5 UML 建模模块下载和安装说明
NetBeans 5.5 UML 建模模块下载和安装说明
NetBeans 5.5™ UML 建模模块为 NetBeans IDE 提供了 UML 建模功能。通过 UML 建模功能，分析师和设计人员可以使用一种标准的建模语言来设计应用程序；开发者则可以根据 UML 模型来生成源代码，并通过对源代码执行的更改来更新此模型。
您可以通过 NetBeans 更新中心下载并安装 UML 建模模块。要访问更新中心，请在 NetBeans IDE 主菜单中单击“工具”>“更新中心”。
Mac 用户请注意：Macintosh OS X 平台目前不支持 UML 建模模块。要获取有关已知问题和解决方法的更多信息，请参见适用于 Mac OS 平台的发行说明。
目录
先决条件
本主题指定了在开始安装 NetBeans 5.5 UML 建模模块之前，必须满足的先决条件。
所需的软件
在试图安装 NetBeans 5.5 UML 建模模块之前，必须首先安装以下软件：
注意：有关安装 NetBeans 5.5 UML 建模模块的系统要求信息，请参见 UML 建模模块发行说明。
- NetBeans IDE 5.5（以下简称 "IDE"）
下载并安装软件
本部分包含有关下载 NetBeans 5.5 UML 建模模块并在所有支持的平台上进行安装的说明。
注意：如果曾经安装了任何 UML 建模模块的 Beta 版本，则无需卸载 Beta 版本。不过，这会造成安装后期的步骤略有不同，我们将在下面的步骤中加以说明。
- 在 IDE 主菜单中，单击“工具”>“更新中心”。
此时，会出现更新中心向导。 - 在“选择模块位置”页中，选中“NetBeans 更新中心”复选框（如果尚未选中）。
- （可选）取消选中所有其他复选框，以最大限度地减少生成的可用模块列表中的条目个数。
- 单击“下一步”。
IDE 在与 NetBeans 更新中心建立连接期间，将会显示一个进度对话框。 - 在更新中心向导的“选择要安装的模块”页中，滚动到“功能”文件夹下的“UML 建模”节点。
- 选择 UML 建模模块，然后单击“添加”。
在位于右侧的“包含在安装中”窗格中，您会看到 UML 建模模块及其所需的所有相关库模块。 - 单击“更多”按钮可查看 UML 建模项目页。
将打开一个 Web 浏览器以显示此 UML 项目页。 - 返回至更新中心向导，然后单击“下一步”。
- 阅读并接受 4 个 UML 许可证。
将出现“下载模块”页，同时显示下载模块时的进度。注意：如果通过 UML 建模模块的 Beta 版本进行升级，则系统不会提示您接受 4 个 UML 许可证。
- 完成模块下载后，请单击“下一步”。
将为您显示可供查看的证书列表。 - 单击“完成”。
如果通过 UML 建模模块的 Beta 版本进行升级，则会出现“重新启动 IDE”的对话框。请继续执行下一步
如果 UML 建模模块不是通过 Beta 版本进行升级的，则系统会继续执行 UML 模块安装。更新中心向导消失后，仍需要几分钟的时间才能完成安装。当您看到 IDE 窗口左下角显示消息“正在启动模块...完成”时，则表示安装结束。 - 在“重新启动 IDE”对话框中，选择“重新启动 IDE”，然后单击“确定”以继续执行 UML 建模模块的安装。
如果选择“稍后安装”，则在下次重新启动 IDE 时才会安装 UML 建模模块。
- 请阅读发行说明页以了解有关此发行版本的重要信息。
增加内存设置
在 IDE 中处理 UML 项目时，应增加 NetBeans 的缺省内存设置。安装了 UML 模块后，请执行以下步骤以确保在处理 UML 项目时 IDE 中的内存设置正确无误。
- 在 IDE 主菜单中，单击“帮助”>“关于”，然后单击“详细信息”标签。
- 通过查找“当前目录”字段，确定安装 NetBeans 5.5 IDE 时所对应的安装目录
的路径。
例如，缺省安装目录为C:\Program Files\netbeans-5.5(Microsoft Windows)。 - 转至通过上一步确定的 NetBeans IDE 安装目录
。 - 转至
etc/目录。 - 编辑
netbeans.conf文件。 - 在
netbeans_default_options行中，将-J-Xmx128m命令行开关选项更改为-J-Xmx512m。
注意：如果在执行了此步骤后，处理大型文件时仍出现堆溢出的问题，则应当继续增加该值。
最近的积累 - []
最近的积累 - []
linux网卡模块：mii.o，再是insmod具体的驱动模块。
vsftpd：使用xined 做demon无法绑定21端口，为使vsftpd独立监听启动，改xined.d/vsftpd中的disable为yes。vsftpd.conf中设为listen=YES，ipv6补丁
重定向：0标准输入、1标准输出、2标准错误、&全部。例如，ls -a 2 >filename 错误信息。
mencoder编解码：mencoder -ovc format -oav format sourcefile -o dest。
sql：1st范式：不存在两行完全相同；2nd：部分依赖于主键不存在，如果有则分成多个表；3rd：消除传递依赖。
sourceinsight的解析*.cc问题：preference中C++language->doc type->加入*.cc->重解析
ipv6suite 使用：cmakelist.txt，omnet.ini，*.ned，*.xml，将*.ned加入../../etc/default.ini中可以不 用preload；xmllint --noout --valid *.xml判断xml的正确性至无输出。移动节点xml需要定义mn.linklayer[0].NWIName="wireless Ethermodule"；优化DAD、HMIPv6也在这里配置。udp流numofUdpApps配置数量，Udpname，server见 pingnetwork，路由时的下跳是sitelocal地址。看MN的网络层信息： *.MN.networkLayer.proc.forwarding.core.routingInfoDisplay = true
TCP粘包的问题大家是怎么处理的
TCP粘包的问题大家是怎么处理的
如果网速过慢，客户端两次发送的数据可能会被服务端一次就全部接收。
那么这种情况下要如何分清服务端接收到的数据包是客户端几次发送的呢！
有一种方法是给每次发送的数据包加上数据包的长度，可是这仲做法如果网上出现丢包怎么办呀！ 问题点数：0、回复次数：19Top
1 楼fisker0303（天塌了,地陷了,小花狗不见了.）回复于 2005-06-13 09:43:01 得分 0
http://www.xiaozhou.net/ReadNews.asp?NewsID=240Top
2 楼fisker0303（天塌了,地陷了,小花狗不见了.）回复于 2005-06-13 09:43:34 得分 0
一般来说，TCP的可靠性是应该充分相信的。Top
3 楼karllere（我想换工作，哪有招C++游戏程序员的联系我。）回复于 2005-06-13 10:39:02 得分 0
我想用下面的方法实现分包
每一个数据包在发送时定义如下格式
数据包长度|数据包序号|数据包内容
可是上面的形式在一定的情况下是错误的
就是如果在客户端一份数据被自动分成两个数据包发送，而且第二个数据包在途中丢失，那么数据就不能完整的到达服务端了。
大家谁有TCP报头的数据格式资料啊！Top
4 楼helldream2002（）回复于 2005-06-13 10:51:09 得分 0
只要协议定义得好，粘包就好解决
一般来说协议中都应该包含包头和数据长度Top
5 楼younggle（洋溢）回复于 2005-06-13 10:57:44 得分 0
自己定义一个协议头，协议头的长度是固定的，协议头包含数据内容的长度。
接收消息时，先接收固定长度的协议头，然后根据协议头中数据的长度再接收数据内容。
也就是说，一条消息分2次接收。
这样可以处理粘包问题的。Top
6 楼alfwolf（木马煞）回复于 2005-06-13 10:58:18 得分 0
是的,这样的情况你必须定义你的数据包的格式,包头-信息类别-长度等,必要时需要加校验位和结束字符.
但是TCP报文是可靠的.Top
7 楼qrlvls（ 空 气 ）回复于 2005-06-13 11:11:01 得分 0
通过自定义帧格式来完成，在帧中加入长度字段Top
8 楼qrlvls（ 空 气 ）回复于 2005-06-13 11:11:27 得分 0
同意 karllere ，不过序号不需要，因为 TCP 不会乱序Top
9 楼karllere（我想换工作，哪有招C++游戏程序员的联系我。）回复于 2005-06-13 14:15:44 得分 0
请看下面的这两组数据
报头 | 报文
10 ABCDEFGHIJ
8 ABCDEFGH
假设以上报文的第一组被操作系统分成两次发送
第一次为 10ABCD
第二次为 EFGHIJ
如果第二次的数据丢失，下一组数据8ABCDEFGH又到达了。
那么在缓冲区中就会有这样的形式10ABCD8ABCDEFGH
根据数据格式定义，在一次读取数据时就会取出10ABCD8ABCDE
如果出现以上情况的话就会造成所有后续发来的数据包全部读取错误。
Top
10 楼karllere（我想换工作，哪有招C++游戏程序员的联系我。）回复于 2005-06-13 19:23:05 得分 0
MFC中的CSocket类内部会自动处理粘包和丢包的问题吗？Top
11 楼cryptonym（想裸睡）回复于 2005-06-13 22:13:41 得分 0
tcp的协议层给你处理了丢包，所以你都不需要考虑丢包的问题。
你把收到的数据放倒一个buffer里，从里面找header，然后解析出数据就ok了。
如果udp的话会乱序，tcp都不需要考虑这些的。Top
12 楼AntonlioX（做人要厚道）回复于 2005-06-13 22:39:08 得分 0
可以使用如下的方法接收数据：
需要循环调用Receive的 知道你实际接收的字节数＝＝ 你本来打算接收的字节数
下面是我的程序中的一段代码
BOOL MyReceiveData(CSocket *psocket,char *data,DWORD len)
{
DWORD left,idx,ret;
left=len;
idx=0;
while(left>0)
{
ret = psocket->Receive(&data[idx],left,0 );
if( ret == SOCKET_ERROR)
{
return FALSE;
}
left-=ret;
idx+=ret;
}
return (idx==len)?TRUE:FALSE;
}Top
13 楼hxzb7215191（天行健,君子以自强不息）回复于 2005-06-13 23:10:25 得分 0
老问题，这东西还是使用自己定义的协议。
说明你的数据包的大小。
使用那个socket的控件就爽多了。
Top
14 楼karllere（我想换工作，哪有招C++游戏程序员的联系我。）回复于 2005-06-14 10:52:13 得分 0
CSocketFile 是完成什么优化工作的呢！
在MFC的示例中总是说要将CSocket、CSocketFile和CArchive联合使用来完成信息的收发工作。
可是我感觉这样还不如真接用CAsyncSocket::Receive方便呢！
我就在想...
CSocketFile是不是内部有处理粘包的机制啊！
还有就是对于Socket的一切猜想都需要一个
能不能给我提供一个呀！Top
15 楼wilddragon（东瀛倭族自治州州长）回复于 2005-06-14 17:36:38 得分 0
MFC的CSocketFile有毛病的，千万别用。在粘包时经常出问题，最后我放弃用它，就好了。
用CAsyncSocket::Receive接收下来以后，自己处理吧。Top
16 楼qianyong325（帝王企鹅）回复于 2005-06-14 17:55:04 得分 0
发送数据的协议定好，一般有 包头，长度，数据段，校验（有的还有包尾），然后写个协议控制层专门处理分包，粘包的问题linux kernel 体系结构 - [Linux]
linux kernel 体系结构 - [Linux]
linux 系统软件体系结构如图，user mode 进程需要通过glibc作一个到kernel mode 的转换
Linux kernel 的体系结构
进程管理：linux/arch/xxx 依赖于具体体系结构
内存管理：linux/mm/
VFS： linux/fs
协议栈： linux/net
设备驱动：linux/drivers
TCP window size (zz) - [Networking]
TCP window size (zz) - [Networking]
How many of you have notice that no matter you have a 100 Mb line youonly get near 2 Mbps, well that is
because the TCP window size is only of 32 kB or 64 kB on Linux (depends
on distribution) and 8 kB on M$ Windows.
The TCP window size is the amount of data that will be send on a
connection before a host stops and waits
for an acknowledgment. This is used by TCP to prevent congestion.
Ideally it should be:
Window size = Bandwidth x round trip time
@@WARNING@@
* If your window size is too small, you won't use the network to it's
full capacity
* If your window size is too big, you risk overloading the network
and creating congestion and packet loss
* On a WAN, setting the TCP window size correctly plays a big part in
getting good performance
(it can easily double performance or more)
The peak bandwidth of the link is typically expressed in Mbit/s. The
round-trip delay for a link can be measured with traceroute, and for
high-speed WAN
links is typically between 10 msec and 100 msec. For a 60 msec, 120 Mbps
path, the bandwidth*delay product would be 7200 kbit, or 900 kByte (kB).
...so here is how to change the
TCP Window size on Linux in order to achieve higher bandwidth.
#cd /proc/sys/net/core
#ls
message_burst netdev_max_backlog rmem_default wmem_default
message_cost optmem_max rmem_max wmem_max
-------
(The secret are on these files)
/proc/sys/net/core/rmem_default - default receive window
/proc/sys/net/core/rmem_max - maximum receive window
/proc/sys/net/core/wmem_default - default send window
/proc/sys/net/core/wmem_max - maximum send window
--------
# cat wmem_default wmem_max rmem_default rmem_max
65535
65535
65535
65535
#
(If you change these numbers you are changing the TCP window)
The theorical values are 65535 on all of them because asume bandwidth of
100
Mbits/s and the round trip time was 5 msec, the TCP window should be
(100x10^6) bytes/sec * (5x10^-3) sec = 65000 bytes or 65 kilobytes
or
500x10^3 bits (65 kilobytes)
But imagine right now we (the UPR) have a DS3 (45Mbit/sec) with Sprint
and the average
round trip is 115 ms (do ping to anywhere outside and you will get
higher numbers)
So the computation will be:
45 Mbit/sec * 115 ms
= 45e6 * 115e-3
= 5,175,000 bits / 8 / 1024
= 631 KBytes
That means that our ideal TCP Window is 631 KBytes.
# cat 646875 > /proc/sys/net/core/wmem_max
# cat 646875 > /proc/sys/net/core/wmem_default
# cat 646875 > /proc/sys/net/core/rmem_max
# cat 646875 > /proc/sys/net/core/rmem_default
Well, hope this works for you. Note that this is not using the Internet2
link yet. Probably will
require a much smaller TCP Window. Please let me know if you find any
difference on performance.
DISCLAIMER: These are teorical numbers and are not guaranty to work for
everyone in the same way.
For M$ Windows 9x users please refer to:
http://moat.nlanr.net/Software/TCPtune/
REFERENCES:
http://dast.nlanr.net/Articles/GettingStarted/TCP_window_size.html
http://ncne.nlanr.net/research/tcp/testrig/
A very useful presentation:
http://ncne.nlanr.net/training/techs/1998/980128/talks/welch
General Info:
http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html
http://www.psc.edu/networking/perf_tune.html (outdated 1999 but useful)
http://www.ncsa.uiuc.edu/People/vwelch/net_perf_tools.htm
ORACLE 10g RAC failover and load balance configuration - [Database]
ORACLE 10g RAC failover and load balance configuration - [Database]
Oracle 10g rac 始支持两个instance的failover和loadbalance。示例如下：
VMRACTEST.HF.COM=
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = 172.16.209.47) (PORT = 1521))
(ADDRESS = (PROTOCOL = TCP) (HOST = 172.16.209.49) (PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = vmractest.hf.com)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5))
)
)
如上配置，若使用oci client连接RAC则client将连接到172.16.209.47 或 172.16.209.49的任意一台实例上，假设我们连到了49上。TCP Connection状态为ESTABLISHED。当49的instance发生故障，该client端TCP连接状态变为Close_WAIT，不要 以为连接已断。当我们执行数据库操作时，oci将重连到47的TCP Connection