Add your own alternative version
Stats
151.8K views 6.1K downloads 59 bookmarked
Posted
2 Jan 2002
|
Comments and Discussions
|
|
Hi, I have read the article you wrote, and I need some help here.
Here's the problem: I need to take a
file, the file may be any file, opened with something like a Browse button, and
to encrypt it, then send it to a specific address, the addres on the net is
also given by me, and there, if the file arrives safe at the address I wanted,
it will be decrypted and can be read by the receiver. I have some code, but I
have to use the sockets programming stuff, and to know the specific port also,
so that , if I would like, the program may run on the same machine as well,
just sending and receiving at the same port.
Can you send me someinfo and code about that?
Thanks,
steve
|
|
|
|
|
But DCOM wasn't perfect; it introduced new complexities. Like COM, whenever a server-side component is updated using DCOM, the type library information changes due to binary incompatibility. With DCOM, these changes need to be propagated to existing client machines. DCOM doesn't provide a mechanism for dynamically updating and binding to type library information; such information is stored in the registry, or with COM+ in the COM+ catalog. DCOM is a "chatty" protocol, pinging clients regularly to see if the clients are still alive. And because it doesn't support batch operations, it takes almost a dozen roundtrips to the remote server to complete a single method call. Using DCOM through firewalls becomes problematic because it dynamically allocates one port per process (configurable through the registry) and requires UPD and TCP ports 135-139 to be open. An alternative for enabling DCOM through firewalls exists by defining Tunneling TCP/IP as the underlying transport protocol. This allows DCOM to operate through some firewalls via port 80. But it's not very reliable, doesn't work through all firewalls, and introduces other limitations (lack of callback support, etc.). DCOM has certainly evolved over the years, in an effort to accommodate the demands of a changing environment. But because of its roots in older binary and component-based protocols, it still fails to deliver the flexibility needed in today's enterprise. DCOM is still inefficient, cumbersome to deploy and requires a fair amount of manual maintenance.
From the site http://msdn.microsoft.com/library/enus/dndotnet/html/webservicesdcom.asp
The author points out the problems of DCOM, but does not give out reasons clearly. I think the most fundamental problem of DCOM uses the net communication pattern 1!
Yuancai (Charlie) Ye
See 30 OLEDB samples
Use of free SocketPro for creating super client and server application
www.udaparts.com
|
|
|
|
|
Hi, All
I updated SocketPro with its documentation and more samples. See the site http://www.udaparts.com. It will takes a while for Codeproject to publish my this updated article
Yuancai (Charlie) Ye
|
|
|
|
|
I've tried to install Spinstaller.msi on several Windows XP machines and always get the cryptic "installation not support on this processor type" pop-up error. Is this due to OS incompatibility, missing component, or (as indicated) the processor type, as far as I can tell the usual Intel cores...
|
|
|
|
|
Hi, robinsonra2:
I guess you are using WinXP 32bit version. If my guess is correct, please use the below link to download. It seems to me you used installation for x64bit window platforms.
http://www.udaparts.com/socketpro5_x86.zip[^]
|
|
|
|
|
Very excellent, but can You create a demo for transfer huge from server to client ?
Thanks.
Ivan
|
|
|
|
|
Hi, Ivan:
Yes! there is an example named as MultiSvsClient.exe inside the package. You can also use SocketPro to send a file from a client to a server. Further you can use two socket connections to send and get files to and from a server in parallel with no problem at all.
best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
require code for "distributed system" client server file transfer code in vb with back end oracle
|
|
|
|
|
Hi,
See the samples MoveFile and MultiSvsSample inside SocketPro at www.udaparts.com.
Yuancai (Charlie) Ye
RDB, a tool for fast and securely accessing remote databases with dial-up, cable, DSL and wireless modems anywhere
Fast and securely accessing all of remote data sources anywhere with SocketPro using batch/queue, non-blocking and parallel computation
See 30 well-tested and real OLEDB examples
www.udaparts.com
|
|
|
|
|
OK, i think it's a good tast. But anyone can tell me the way how to transfer file from client to server. Many thanks.
|
|
|
|
|
Hi,
See the open source projects UFile (client) and UFileSvr (server) inside the SocketPro version 4 at www.udaparts.com. There are two demon projects MoveFile (VB6) and ODBClient (VC++) available to show you how to exchange files between client and server asynchronously without creating any thread.
Now SocketPro is enabled with online compressing, which will certainly speed up exchanging files over low speed networks such as dial-up, cable/dsl, and wireless etc.
As shown in the source code of UFile and UFileSvs, SocketPro divides a file with number of batches and send them in queue.
Should you have any questions, please let me know.
Best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
Hi, Reno:
First of all, I have very little experience with MSMQ and QC. Hopefully my answer is correct. If wrong, please let me know.
There is some similarity between SocketPro and MSMQ. Both processes the requests from clients either asynchronously and synchronously on the surface. However, there is fundamental difference between the two. MSMQ is a connectionless message service where applications do not need to maintain a session, but SocketPro is a connection message service where applications do need to maintain a session. Therefore, SocketPro will process various requests and return results faster without building network connection for each of client requests. I guess that MSMQ will do network connecting and security checking a lot.
SocketPro doesn't directly support transaction, but you can implement transaction inside a SocketPro server application without any problem.
SocketPro is a light software framework which helps you build client and server applications directly on socket for the best performance. It is not designed to be similar to any one of MS products. But it has its own features that other technologies can't provide easily.
Best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
Contrary to other readers, I appreciated your article.
I worked myself on a similar project and I am curious to see your implementation.
Have you heard about GMSOCKS?
Regards
Jeff
|
|
|
|
|
Hi, Jeff:
Thanks a lot!
I don't know GMSOCKS. Could you give the web site and let me see it.
Yuancai (Charlie) Ye
|
|
|
|
|
Unfortunatly i don't have the source access to this middleware.
You can find some abstract information here :
http://www.computer.org/proceedings/cluster/1116/1116toc.htm
It talks about researchs : IEEE International Conference on Cluster Computing
Regards
Jeff
|
|
|
|
|
Hi, Jeff:
Thanks a lot for your message. I am definitely going to see the articles and do somewhat research on it.
Best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
http://mufasa.informatik.uni-mannheim.de/~mfischer/gmsocks-detours-talk-cluster2001.pdf
|
|
|
|
|
Hi, Jeff:
I read through your slides and some docs about cluster and parallel computing. One month ago, I played with MPI (Message Passing Interface) for parallel computing. Basically, MPI is pretty simple in concepts, but it is the difficult to code for a real business application. MPI is written from Socket.
In regards to your GMSOCKS, I am not sure how simple it is although it is pretty similar with my SocketPro. How do you handle multiple calls from different clients and ensure that they don't block each other. Remember that client calls could be blocked if some of calls are lengthy actions. In SocketPro, I use threads and message pumps to gurantee that all of calls don't block by assigning all of lengthy actions onto different threads/message pumps.
Best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
where is the document of your com library.
|
|
|
|
|
Hi,
I will provide the documentations for ClientSocket.dll and SockFile.dll. For the other two COM dlls, I will release the source code of the two. So I don't have to provide any docs for the two. The source code will tell you how to use ClientSocket.dll. In regards to the server side dll, I will also provide the docs with a few examples with source codes. You will see how easy to develop server side applications with SocketPro
Best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
Hi,
You can get the doc from www.udaparts.com Thanks a lot for your interesting.
Yuancai (Charlie) Ye
|
|
|
|
|
First I really get a feeling you don't understand what DCOM/CORBA does.
DCOM/CORBA is sooooooo much more than just plain socket transfer.
1)Marshaling Data? Oh, You expecting IP address? Here we go have fun with my Picture scanned at 14000x14000 dpi.
2)Do you handle security in SockPro?
3)Do you release Interfaces at sometime???
MTU/Nagle etc.
Nagle algorithm is turned on by default. What make you think CORBA and DCOM turn it off?
>However, these technologies have one common and fundamental problem that all
> of calls between a client and a server are blocked for a returned result
> (please correct me if this is wrong). A client stays still, and has to wait
> for a while after sending a request to a server. If the request is a
> lengthy action, the client application seems to be dead to a user.
In other words you want to be asyncronously notified when action is complete?
Hmm, Chapter2 Event sinks/ConnectionPoints. Create threadpool, assign worker.. notify back.
So let's see:
>All of applications developed from this framework will has the following BIG
> BIG BIG .... advantages plus other numerous advantages:
> 1)Non-blocking/blocking, parallel computing client and server.
Same as others.
> 2)Both client and server run at the fastest speed because of Nagle algorithm.
Nope could not be that. Less overhead because you hardcoded security + object, dropped wrappers - yes.
> 3)Cross-platform data communication and cross-language development
Use CORBA.
>ware, SocketPro still runs 30% faster even though SocketPro runs in the
> blocking mode according to my experiments.
Well this could be, but if you are, like me, storing data in the database - database runs 10x slower than anything else. Is file transfer good way to test DCOM performance?
>Other advantages includes:
>Simple installation and security setup.
Just about only place I'll give you some credit. Been long time but I still remember the bruises of DCOMConfig.
|
|
|
|
|
Hi, Brian:
Thanks a lot for your input. I am glad to answer your questions. First of all, I am not professional with CORBA and Java/RMI.
1)Marshaling Data? Oh, You expecting IP address? Here we go have fun with my Picture scanned at 14000x14000 dpi.
It is your preference. I don't want to comment it.
2)Do you handle security in SocketPro?
Yes, SocketPro has a simple mechanism to handle security. A user should implement his or her own security check if needed. For your easy testing the package, I did't implement the security check, as indicated at the post. You can easily do security check either when a cilent tries to conncet to a socket application server or when a client sends you password and user id. Additionally, you can do also incorplated SSL with SocketPro. There is nothing to prevent you from using SSL and data encryption.
3)Do you release Interfaces at sometime???
The SocketPro server component is not written from DCOM or COBRA. No interfaces involved. The Client components, ClientSocket.dll, SockFile.dll, SBroker.dll and DResolver.dll, are COM objects written from ATL. You can use them from any languages on Win platforms.
4)Nagle algorithm is turned on by default. What make you think CORBA and DCOM turn it off?
I didn't say that Nagle algorithm is turned off in CORBA and DCOM. What I said that Nagle algorithm in CORBA and DCOM can't take advantage of Nagle algorithm because calls of CORBA and DCOM are internally synchronous, and not asynchronous. I am 100% sure that coalescing works in SocketPro. However, I doubt that coalescing in CORBA and DCOM does although Nagle algorithm is turned on CORBA and DCOM. If you are still not sure this, I am able to tell you to design an experiment to test what I said.
5)In other words you want to be asyncronously notified when action is complete? Hmm, Chapter2 Event sinks/ConnectionPoints. Create threadpool, assign worker.. notify back.
I know all of Event sinks/ConnectionPoints, thread pools, and work threads. It is trival but painful to create asyncronously notifications through worker thread with the price of data synchronization problem and mess in coding logical. The point is that SocketPro get notifications WITHOUT CREATING WORKER THREAD using the nature of window socket. Notifications WITHOUT CREATING WORKER THREAD saves you a lot work!!!
6)Non-blocking/blocking, parallel computing client and server.
Same as others.
I do't agree with you on this. If you use DCOM and CORBA, I bet you have to use worker threads for blocking/blocking, parallel computing either directly or indirectly. If using socket, you will never have to do so with only one exception if you are able to take advantage of WSAAsyXXXX functions. Additionally, pay attention to "All of client function calls, which lead to data movement over internet, can be switched between blocking and non-blocking modes at your will after a socket is created.". Can DCOM and CORBA do this? I bet DCOM and CORBA can't do that.
7)Both client and server run at the fastest speed because of Nagle algorithm.
Nope could not be that. Less overhead because you hardcoded security + object, dropped wrappers - yes.
I don't think you really understand what I said in the short article. Please read through the article more carefully. The SocketPro takes advantage of coalescing of Nagle algorithm, which makes SocketPro run at the fastest speed by reducing the number of data packets. If you are not good with Socket, please see the site http://tangentsoft.net/wskfaq/.
8)Cross-platform data communication and cross-language development
Use CORBA.
Like SocketPro, CORBA is one of possible selections.
I am waiting for your questions. You are welcom to give me your questions and concerns.
Yuancai (Charlie) Ye
|
|
|
|
|
I think I understand what you tried to accomplish.
Something simple to asynchronously to comunicate with. Easy to config. Object would async notify back. Object is nor loaded/nor released dynamically. Implement your own security. Request params is not typed., etc. Each server thread has one and only client.
If so then why are you comparing this to COM/DCOM?
I'll change my rating of this article also it seems many others rated it pretty poorly.
|
|
|
|
|
Hi, Brian:
Again, thanks for your input. At this time, I guess you just understand the surface of SocketPro. I would like to continue answering your questions further.
1)Something simple to asynchronously to comunicate with.
Answer: Something simple to asynchronously to comunicate with, and also simple to synchronously comunicate with. The two running modes, blocking and non-blocking, can be switchable at your will. If functions are called in the non-blocking mode, the coalescing will automatically happen through Nagle algorithm for reducing the round-trips of data over internet by default.
2)Easy to config. Object would async notify back
Answer: Right! Additionally, I think COM/DCOM object sync notify back. There is difference between the two.
3)Object is nor loaded/nor released dynamically.
Answer: Actually, the objects at the server side is dynamically created and destroyed. I can't use the words load and release.
4)Implement your own security.
Answer: This is true.
5)Request params is not typed., etc. Each server thread has one and only client.
Answer: I don't understand "Request params is not typed.", In regards to relationship between the server threads and clients, it is tough to use a few sentences to describe it clearly. In comparison to common data synchronization, the data movement syschronization over a socket is quite special. Two threads are not able to receive or send data on a socket at the same time, but one of the two may be able to receive data and the other one to send data over a socket sumultaneously. One main thread does have multiple clients associated, and one client must has one or more threads/queues to process requests. Some client calls will not create a thread/message, but some client calls will do. All of this are dynamically finished based on if a request is lengthy action or not. If a thread is in idle for a specific time, it is killed for releasing system resource. If a thread is needed, just recreate it one automatically. This is totally isolated from the client side.
6)If so then why are you comparing this to COM/DCOM?
I didn't compare this with COM, but does to DCOM. Both DCOM and SocketPro help you build up client and server applications. However, there are some difference between the two. Some of important and special SocketPro features can NOT be found in DCOM, CORBA and Others. Right?
The two attractive features are:
A. Blocking/non-blocking and parallel computing without using worker threads.
B. Batching calls through coalescing data of Nagle algorithm.
7)I'll change my rating of this article also it seems many others rated it pretty poorly.
I am confident to my work. The rates doesn't influence me very much. This happens because English is not my native languange and people doesn't really what I did.
Best regards,
Yuancai (Charlie) Ye
|
|
|
|
|
|
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
|
|