高手不难,高分相送...(300分)

  • 主题发起人 主题发起人 maming
  • 开始时间 开始时间
M

maming

Unregistered / Unconfirmed
GUEST, unregistred user!
如果你碰到那些很早就使用电脑的用户?他们的机器很早,可电脑水平很高。
所以要求高得很,不过这个问题我觉得很正常,我也很想实现这种技术
"做三层的应用时,在LAN中很好,联接数据库,打开数据表,保存数据都很快,
根本感觉不到慢,几十个客户端也不会有问题。可如果大批量处理或是在internet
上就问题来,不是程序出错,而是在联接数据库,打开数据表,保存数据都很慢,
客户端在这三种操作时那界面就象死机,所以产生了以下想法,能不能在上面三种
操作时创建一个线程在后台执行,前面界面不死,当然要控制不能做其它的操作,
就显示一个正在(联接,打开,保存)数据的窗口,整个程序还能最小化。
甚至还要能通过这个显示的窗口中止当前的操作(联接,打开,保存);

就象在263玩游戏一样,后台的数据处理对前台的界面没有影响。可以各位大
虾早有实现了的,可否贴出来。重金酬谢!我做了数据联接的,可没有实现上面那种效果。

请试用下面的代码,就可以看到效果,可会在退出时出错,这就是我的目的
function mconnect(p:pointer):longint;stdcall;
begin
//这里如果用了vcl就在退出时出错;
form1.scoketconnect1.open;
end;
procedure TForm1.Button1click(sender: Tobject);
var mthreadid: Dword;
begin
createthread(nil,0,@mconnect,nil,0,mthreadid);
if mthreadid=0
then
showmessage('no thread');
end;

而当我要用clientdataset1去联接scoketconnect1时就出错了,不能打开数据。
//*************************************
我这样做的时候又有一个问题:在syconnect中说明了;
TThreadQuery1 = class(TThread) { 声明线程类 }
private
Fclientdataset: Tclientdataset;
procedure syconnect;
protected
procedure Execute;
override;{ 执行线程的方法 SocketConnection: TSocketConnection;
}
public
constructor Create(clientdataset: Tclientdataset);
virtual;
{ 线程构造器 }
end;

procedure TThreadQuery1.syconnect;
begin
{这样的话就可以实现界面不死,但不能操作它也不能用与它相联的socketconnect}
FClientDataSet.Open;
{用Form1.ClientDataSet1.Open;这样的话界面就会死但可以使用clientdataset1,和
其它的clientdataset也就是说那个与socketconnect就是正常的联接了}
end;

procedure TThreadQuery1.Execute;{ 执行线程的方法 }
begin
try
Synchronize(syconnect);
except
end;
end;

{ 线程查询类的构造器 }
constructor TThreadQuery1.Create(clientdataset:Tclientdataset);
begin
Fclientdataset := clientdataset;
inherited Create(False);
FreeOnTerminate := True;
end;

procedure Tform1.button1click(sender:Tobject);
begin
threadquery1.create(form1.clientdataset1);
end;

前面提过一次,可能没有说清楚,两次一起600分,请高手们多多指教。
http://www.delphibbs.com/delphibbs/dispq.asp?lid=567635这是前面的问题。
 
好像不必这么麻烦吧?
在联接,打开,保存数据库的语句后面插入一句
Application.ProcessMessages;
将控制权交还给系统不就行啦?我就是这么处理的。
 
哦,用application.processmessages;对这种远程的操作不起作用的,
象scoketconnect.open和clientdataset.applyupdate有时要很长的时间的。
等到执行到application.processmessage时已操作完了。
 
看来要用多线程程序,可惜我没做过。
 
将所有和中间层相关的东西通通在线程中处理,不要只处理打开.
用自己的数据结构保存查询到的数据.
 
那样的话就会很麻烦啊!
 
.....
procedure TThreadQuery1.syconnect;
begin
{在这里放FclientDataSet.open可是Form1.ClientDataSet1.Open
界面会死但可以使用clientdataset1,和
其它的clientdataset也就是说那个与socketconnect就是正常的联接了}
end;

procedure TThreadQuery1.Execute;{ 执行线程的方法 }
begin
try
{这样的话就可以实现界面不死,但不能操作它也不能用与它相联的socketconnect
更可气的是退了时报非法操作错误关都关不掉,为什么传个Query进来就可以真是
搞不懂了}
FClientDataSet.Open;
Synchronize(syconnect);
except
end;
end;

.....
 
procedure TForm1.Button1Click(Sender: TObject);
begin
TThreadquery1.create(form1.clientdataset1);
//线程创建时有误
end;

我用你的程序,只改了这里,完全可以运行通过.
不知道你怎会出错?
 
to alter:你试了,用第二个clientdataset去联form1.clientdataset1的remoteserver吗?
还有,你是在execute使用Fclientdataset.open还是在syconnect中呢?
那个button1click事件是我打错了,你改成什么样的呢?
 
第二个ClientDataSet通过第二个SocketConnect连接RemoteServer.如果采用线程的话,没有问题.
另外,肯定要用Synconnect实现同步
 
哦,如果每一个clientdataset用一个socketconnect的话,那不是很好,
而且那样会很慢的,再说系统中有负载平衡功能。会有些不好做,
如果将clientdataset放在synconnect中,则用户界面一样的象死机。
 
不过我觉得用Socket始终都会存在响应慢的问题,
如果用DCOM或Corba比较好一些.做产品,最好不用SocketConnect.
 
可不只限lan啊!
下一步就是internet上用了,所以客户端用socketconnct了。
 
DCOM和Corba可以跨路由
 
用DCOM和Corba我还是想把联接,打开,保存做成后台运行。
 
DCOM如何跨路由?
关注该问题。
 
to alter:DCOM和Corba可以跨路由?
你是不是做过这方面的应用?如果做过可否给些个例子或是说下设置,
或是你有这方面的资料?共享出来让大家学习学习,如果可以的话,我把这些资料放
到我的主页上让大家下载,你说呢?
 
请看Demo
http://alter.51.net/down/cdsthread.zip
 
上面的Demo是用线程实现ClientDataSet的打开
对于Corba的跨路由,需要在网关上放置Corba GateWay,因此很难做到.
对于DCOM的跨路由,请看文章:

<P>
This article is intended to provide the reader with information on how to configure the Distributed Component Object Model (DCOM) to work through a firewall. It assumes that the reader is familiar with the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), DCOM, and understands the basics of firewall technology. Please note that the port restriction procedures outlined below only work on Microsoft&amp;reg;
Windows NT&amp;reg;;
Microsoft Windows&amp;reg;
95do
es not include this functionality at this time (don't worry, it isn't necessary in most cases). Also note that much of the discussion in this article is also relevant for remote procedure call (RPC) applications which use dynamic ports. This makes sense considering that the features mentioned below are really implemented in the RPC subsystem which DCOM leverages to communicate across the network.</P>
<P>
Unlike most Internet applications which have fixed TCP and/or UDP ports, DCOM dynamically assigns&amp;#151at run time&amp;#151one TCP port and one UDP port to each executable process serving DCOM objects on a computer. That is, even if a process is hosting 2,000 clients and 50,000 objects, any client wishing to communicate with objects owned by it will always connect to the same TCP or UDP port. Clients discover the port associated with a particular object by connecting to and using the services provided by DCOM's Service Control Manager (SCM). The SCM always operates at a fixed network port on every computer;
in the Internet case this is always port 135 for both TCP and UDP. The SCM offers several RPC-based (not DCOM/ORPC-based) services which handle operations like: &amp;quot;create a new COM class object for me and tell me what TCP and UDP port it is on&amp;quot;
or &amp;quot;I have an interface pointer, tell me where I need to go to actually use it&amp;quot;, etc. A much more technical explanation of this process and of the DCOM wire protocol in general isdo
cumented in the <a href="/isapi/gomsdn.asp?TARGET=/library/specs/distributedcomponentobjectmodelprotocoldcom10.htm">Distributed Component Object Model Protocol -- DCOM/1.0</a>.</P>
<P>
DCOM's dynamic port allocation feature offers great flexibility in that programmers and administrators alike are free from the burden of having to configure (or hard code) applications to specific ports, free from resolving conflicts between multiple applications attempting to use the same port(s), and so on. Unfortunately, because DCOM (by default) is free to use any port between 1024 and 65535 when it dynamically selects a port for an application, it is rather &amp;quot;firewall unfriendly&amp;quot;
out of the box. Configuring your firewall to leave such a wide range of ports open would present a serious security hole. Microsoft's developers realized this and have implemented a feature that allows you to restrict the range of ports that DCOM will use to assign to applications.</P>
<P>
You should be aware that callbacks in DCOM are <I>not</I> handled on the same connection that is used for client/server method calls. When a server makes a callback to a client, it creates a new connection to the client and sends method calls over that separate channel. In other words, DCOM treats callbacks just like any other client/server method call, except that your &amp;quot;client&amp;quot;
is really a server and the &amp;quot;server&amp;quot;
is really a client. In some circumstances (this is <I>very</I> rare), you may need to configure port restrictions on your clients if your firewall restricts what ports machines on the inside can connect to on the outside.</P>
<P>
Also note that if you want to use callbacks through a firewall, you must use TCP. The reason being that when the server makes a call to the client, the source port will not be within the range below and thus when the client sends a reply to the server's source port, it will not be able to penetrate the firewall. This is not a problem with TCP because most firewalls keep track of TCP connections and permit bidirectional traffic on connections, regardless of the source port, as long as they are opened from a machine on the inside.</P>
<P>
One last thing before I continue, the client <I>must</I> be able to reach the server by its actual IP address. You cannot use DCOM through firewalls thatdo
address translation (i.e. where a client connects to virtual address 198.252.145.1 which the firewall maps transparently to the server's actual address of, say, 192.100.81.101). This is because DCOM stores raw IP addresses in the interface marshaling packets and if the client cannot connect to the address specified in the packet, it won't work.</P>
<P> Please also read the <A HREF="#warning">warning</A> for the DCOMCNFG utility included with the Windows NT 4.0 Service Pack 4. </P>
<P> <A HREF="#top"><IMG SRC="/com/images/top-of-page.GIF" WIDTH="11" HEIGHT="15" BORDER="0" ALT="Up">Back to contents</A></P>
<H3><A NAME="config"></A>Configuring DCOM to Use TCP Only</H3>
<P>
Here is a rundown of the transport protocols that DCOM will use depending on the client/server platform:</P>
<P>
<table border="1">
<tr>
<td bgcolor="#3366cc"><font color="#FFFFFF"
face="Arial"><strong>Platform</strong></font></td>
<td bgcolor="#3366cc"><font color="#FFFFFF"
face="Arial"><strong>Protocol</strong></font></td>
</tr>
<tr>
<td><font size="2" face="Arial">Microsoft Windows NT 4.0
&amp;lt;-&amp;gt;
Windows NT 4.0</font></td>
<td><font size="2" face="Arial">UDP</font></td>
</tr>
<tr>
<td><font size="2" face="Arial">Microsoft Windows NT 5.0
&amp;lt;-&amp;gt;
Any</font></td>
<td><font size="2" face="Arial">TCP (*)</font></td>
</tr>
<tr>
<td><font size="2" face="Arial">Microsoft Windows 95 or Windows 98
&amp;lt;-&amp;gt;
Any</font></td>
<td><font size="2" face="Arial">TCP </font></td>
</tr>
<tr>
<td><font size="2" face="Arial">DCOM for UNIX
&amp;lt;-&amp;gt;
Any</font></td>
<td><font size="2" face="Arial">TCP</font></td>
</tr>
</table></P>
<P>
<cite>&amp;#42;
When a Windows NT 4.0 client attempts to connect to a DCOM server running anything but Windows NT 4.0, there will be a 30-45 second delay while it attempts to connect via the UDP protocol. Windows 95 and Windows 98, Windows NT 5.0, and DCOM for UNIX (including Microsoft's DCOM for UNIX product and Software AG's EntireX product) always use the TCP protocol.</cite></P>
<P>
The Windows NT 4.0 implementation of DCOM uses UDP wherever it can because benchmarks show that it can outperform TCP in certain scenarios. Unfortunately, it is very difficult to make UDP applications work through firewalls without exposing your network to unnecessary risks. Before continuing, be sure you make TCP the default protocol on all Windows NT servers by moving the &amp;quot;NCACN_IP_TCP&amp;quot;
value to the top of the list in the <I>DCOM Protocols</I> named value of the <B>HKEY_LOCAL_MACHINE/Software/Microsoft/Rpc</B> registry key using regedt32.exe. To eliminate a 30-45 second delay when connecting to TCP only servers, the same change should also be made on Windows NT 4.0 clients. Note that this delay only occurs if you haven't connected to the target server in a while (RPC's connection caching features retain knowledge about the server so that multiple connections in a short period of time are resolved instantaneously).</P>
<P>The Windows NT 5.0 implementation of DCOM will likely default to TCP because it is not possible to implement the SSL and SNEGO security protocols over UDP.</P>
<P> <A HREF="#top"><IMG SRC="/com/images/top-of-page.GIF" WIDTH="11" HEIGHT="15" BORDER="0" ALT="Up">Back to contents</A></P>
<H3><A NAME="tcp"></A>Restricting the Range of TCP Ports</H3>
<P>There are several registry settings that control the DCOM port restriction functionality. All of the named values listed below are located under the <B>HKEY_LOCAL_MACHINE/Software/Microsoft/Rpc/Internet</B> registry key (which you must create). Remember that you only need todo
this on the server machine, clients will automatically pick up the right port numbers when they connect to the SCM on the server machine.</P>
<P>Note that you must use regedt32.exe to configure these settings, regedit.exedo
es not currently support the REG_MULTI_SZ type required by the <I>Ports</I> named value entry. Also, you must reboot your machine any time you make changes to any of the following registry settings in order for them to take effect.</P>
<P>
<table border="1">
<tr>
<td bgcolor="#3366cc"><font color="#FFFFFF"
face="Arial"><strong>Name </strong></font></td>
<td bgcolor="#3366cc"><font color="#FFFFFF"
face="Arial"><strong>Type</strong></font></td>
<td bgcolor="#3366cc"><font color="#FFFFFF"
face="Arial"><strong>Value</strong></font></td>
<td bgcolor="#3366cc"><font color="#FFFFFF"
face="Arial"><strong>Description</strong></font></td>
</tr>
<tr>
<td><font size="2" face="Arial">Ports</font></td>
<td><font size="2" face="Arial">REG_MULTI_SZ</font></td>
<td width="40%"><font size="2" face="Arial">Specify
one port range per line. <br>Example: </font><br><font
size="2" face="Arial">&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;3000-4000<br>
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;5141</font>
</td>
<td><font size="2" face="Arial">One or more port
ranges. The options below determine the meaning of
this named value. </font></td>
</tr>
<tr>
<td><font size="2" face="Arial">PortsInternetAvailable</font></td>
<td><font size="2" face="Arial">REG_SZ</font></td>
<td><font size="2" face="Arial">&amp;quot;Y&amp;quot;
(don't
include quotes)</font></td>
<td><font size="2" face="Arial"><B>Always</B> set
this to &amp;quot;Y&amp;quot;. </font></td>
</tr>
<tr>
<td><font size="2" face="Arial">UseInternetPorts</font></td>
<td><font size="2" face="Arial">REG_SZ</font></td>
<td><font size="2" face="Arial">&amp;quot;Y&amp;quot;
or
&amp;quot;N&amp;quot;
(don't include quotes)</font></td>
<td><font size="2" face="Arial">If this value is set
to &amp;quot;Y&amp;quot;, then
the <I>Ports</I> named value
indicates which ports should be used for DCOM
applications. If this value is set to &amp;quot;N&amp;quot;,
then
the <I>Ports</I> named value indicates which
ports should NOT be used for DCOM applications.</font></td>
</tr>
</table></P>

<P>It is strongly recommended that you open up a range of ports above port 5000. Port numbers below 5000 may already be in use by other applications and could cause conflicts with your DCOM application(s).</P>
<P> <A HREF="#top"><IMG SRC="/com/images/top-of-page.GIF" WIDTH="11" HEIGHT="15" BORDER="0" ALT="Up">Back to contents</A>
<H3><A NAME="access"></A>Restricting the Internet Accessibility to Specific Applications</H3>
<P>An even greater level of security is afforded if you configure your system so that DCOM applications have to explicitly ask to be accessible through the Internet-accessible port range. To set this up:</P>
<OL>
<LI>
Change the <I>UseInternetPorts</I> named value above from &amp;quot;<B>Y</B>&amp;quot;
to &amp;quot;<B>N</B>&amp;quot;
so that DCOM object servers (and RPC servers) aren't reachable via the Internet-accessible ports automatically. Reboot your machine.</LI>
<LI>Insert the following piece of code before <B>CoInitializeEx()</B> into every DCOM object server application that should be accessible through the Internet-accessible port range:
<PRE><code>
RPC_POLICY rp;
p.Length = sizeof (RPC_POLICY);
rp.EndpointFlags = RPC_C_USE_INTERNET_PORT;
rp.NICFlags = RPC_C_BIND_TO_ALL_NICS;
hr = RpcServerUseAllProtseqsEx
(RPC_C_PROTSEQ_MAX_REQS_DEFAULT, NULL, &amp;rp);
</PRE></code></LI>
<LI>Add &amp;quot;<B>rpcrt4.lib</B>&amp;quot;
to the link command line in your makefile.</LI>
</OL>
<P> <A HREF="#top"><IMG SRC="/com/images/top-of-page.GIF" WIDTH="11" HEIGHT="15" BORDER="0" ALT="Up">Back to contents</A></P>
<H3><A NAME="firewall"></A>Configuring Your Firewall</H3>
<P>The firewall between your server and the Internet should be configured as follows:</P>
<UL>
<LI>Deny all incoming traffic from the Internet to your server.</LI>
<LI>Permit incoming traffic from all clients to TCP port 135 (and UDP port 135, if necessary) on your server.</LI>
<LI>Permit incoming traffic from all clients to the TCP ports (and UDP ports, if necessary) on your server in the <I>Ports</I> range(s) specified above.</LI>
<LI>If you are using callbacks, permit incoming traffic on all ports where the TCP connection was initiated by your server.</LI>
</UL>
<P> <A HREF="#top"><IMG SRC="/com/images/top-of-page.GIF" WIDTH="11" HEIGHT="15" BORDER="0" ALT="Up">Back to contents</A></P>
<P><A NAME="warning"></a><font color=#E80000>WARNING : The DCOMCNFG utility included with Windows NT 4.0 Service Pack 4 provides a property page that allows you to configure port restrictions without having to edit registry entries. Unfortunately, using this property page will cause many of the applications that use RPC on your machine to stop functioning properly the next time your computer reboots. If this happens to you, please delete the <B>HKEY_LOCAL_MACHINE/Software/Microsoft/Rpc/Internet</B> registry key and reboot your computer.</font></P>
<P>&amp;nbsp;<br>
 
后退
顶部