Anyone know of any examples of a TCP sockets proxy application written in Delphi? I am building a small broker application that needs to listen for socket connections on a given TCP port, read a XML data packet sent over the connection, serve the request via TCP to a server chosen from a pool of available back end servers, and deliver the resulting response back to the originating TCP connection.
I am very familiar with TCP and socket-level programming, but would prefer to find sample code as a starting point. If there is something available it would save considerable time and effort since I would not need to reinvent the wheel. I recall seeing a small TCP proxy written in Delphi back in 2003/2004, but seem to have lost track of the link.
Are you looking for a socks proxy implementation? If not, then just start with a server (http would most likely be a good start) and build into it the ability to process your inbound XML data packet, and make the appropriate calls. Something like the Synapse framework would make that a fairly simple project. If you grab Synapse, get the latest version from SVN. It supports all of the latest versions of Delphi.
There is a httpproxy demo for synapse available, that might help if your wanting to implement something more traditional. A good starting http server example is also available.
IPWorks from nSoftware should be considered as a commercial alternative to Synapse. They also have some Biztalk adapters available.
I've used both Synapse and IPWorks, and they are both quite good. I haven't used the referenced BizTalk adapters.
BizTalk Adapters
IPWorks
Related
I've been trying to establish a P2P connections for a couple of weeks. After writing some code and using Indy's components, I've realized that it can not access the peer that is behind the NAT. Furthermore, I've heard about STUN services that provide a client's remote and local IPs and ports. I should say I've already had the other UDP client (server) remote and local IPs, so how can I implement my code and program to work properly? Is there any extra component in Indy's library that I should use?
There is the Ares Galaxy P2P Project I know about some years ago.
There was a recent fork by Christian at https://github.com/CWBudde/AresGalaxy which tries to port it to more modern Delphi versions.
It is a work in progress, but perhaps you may get some very good ideas in this source code, and ask Christian for help/ideas, especially about NAT transversal.
I have to develop a simple application in Delphi XE2. This application will connect to a service running on a server with IP Address(say xxx.xxx.xxx.xxx) with some Port No (say xxxx) using TCP/IP protocol and will get reply from the service running on the server.
I have created two textboxes: txtRequestMsg, txtReplyMsg and a button called Connect.
I need to open a TCP connection and send some data and get some data back in response, something like a ping, but not using ICMP, just raw TCP.
The most commonly used Delphi internet libraries that provide TCP and UDP components for various TCP client (originating) and TCP server (answering) protocols are:
Indy version 10, which is included in the box with your Delphi XE2 installation. Almost any of the demos would probably give you enough information to get started, but be prepared to read documentation, too. Nobody is going to teach you in a single stack overflow question how to write network applications. There are MANY people on Stackoverflow who use this library, and an Indy team member is often on here and answers questions about Indy, and it's well respected, and unless you have a real reason not to use it, you should probably start with Indy. Ask specific questions about Indy when you've tried something, rather than vague questions like this one, please.
ICS by Francois Piette. I like it because the code is smaller and simpler and I find it easier to use than Indy, but fewer people use it. There are people on Stackoverflow who use this library, including me, and Francois himself who is active here on SO.
Synapse. I have only used this a bit, but I know lots of people use it.
I have a custom pair of client/server sockets (TJDServerSocket and TJDClientSocket) which wrap the TServerSocket and TClientSocket in the ScktComp unit. I don't have any issues to fix, but would like to know something. I'd like to add a feature to the client side to automatically search the network for any instances of a server socket (specifically my server component).
I'm open to any suggestions, but has to be specific to the use of the ScktComp unit in Delphi 7.
Here's a link to the components of mine.
Never used the TServerSocket and TClientSocket myself, and I don't have the help files within reach, so I can't immediately see if this would work with those components.
For a project I did I needed something like that too. I ended up with using UDP to broadcast a discovery request (within the same subnet of course). The server, listening on a particular port for such a request, would reply its data back. When multiple servers would exist (a situation that though rare could occur) the client just picked the server with the required service(s) and the least load. That load was part of the data the server send back.
It worked out nice, wasn't all that difficult to write, and turned out reasonably efficient too.
The request protocol is completely up to you. The one I devised allowed clients to send a request detailing the services they need, and servers replying listing their services and the load (= connected clients in active use).
After selecting the server to talk to, a client would register itself for the services it needed, and could use them after that.
Hope this helps.
There are some standard protocols for service discovery. See for example: http://en.wikipedia.org/wiki/Zero_configuration_networking
Mailslots is a nice option here. It'll broadcast to every PC on your subnet. See Jeroen's answer to this question:
Suggestions on writing a TCP IP messaging system (Client/Server) using Delphi 2010
Searching is as easy as port scanning.
If you don't like the brute force approach, the server can register itself to a well known service application (could be a web server), and the client can connect to the service application to ask. It's quieter than broadcasting.
With more information, such as details about the network (who's it for?), I can suggest a more precise answer.
I would like to write a messaging system using TCP IP in Delphi 2010. I would like to hear what my best options are for using the standard delphi 2010 components/indy components for doing this.
I would like to write a server which does the listening and forwarding of messages to all machines on the network running a client.
1.) a.) clients can send a message to server to be forwarded to all other clients
b.) clients listen for messages from other senders (via server) and displays messages.
2.) a.) Server can send a message to all clients
b.) Server forwards any messages from clients to all other clients
thanks for any suggestions
NOTE: I am not writing a instant messaging or chat program. This is merely a system where users can send alerts/messages to other users - they can not reply to each other! NO commercial, shareware, etc links - please! I would like to hear about how you would go about writing this type of system and what approachs you would take, and possibly the TCP IP messaging architecture you would use. Whether it be straight Winows API, Indy components, etc, etc.
If this is Windows only, and you don't want to use 3rd party libraries, then you can skip TCP/IP and go for Mailslots.
Edit: if you want guaranteed delivery, than named pipes is a better solution. This SO question has a few nice answers with Delphi named pipe examples.
A mailslot is a mechanism for one-way
interprocess communications (IPC).
Applications can store messages in a
mailslot. The owner of the mailslot
can retrieve messages that are stored
there. These messages are typically
sent over a network to either a
specified computer or to all computers
in a specified domain. A domain is a
group of workstations and servers that
share a group name.
They don't need a Windows domain, they work over a LAN.
DelphiPages has a nice run-down on doing IPC in Delphi, including mailslots.
--jeroen
If you want save yourself some work and use ready solution:
0MQ
STOMP
AMQP
XMPP
in above order. Last two listed rather in informational purposes.
IMO 0MQ it's best bet - it's well-thought-out, lightweight, fast and reliable.
Looks like publish-subscribe messaging. kbmMW offers one.
There's an instant message client from Aid Aim:
http://www.aidaim.com/products/msgcommunicator/manual_instant-messaging-im-sdk/index.php
About using indy, such as in this demo: indy10clieservr.sourceforge.net OR using the TServerSocket and TClientSocket package
-> now with x64 demo sample from INDY
To get this working reliably is more work than you might think - about 5% effort to get it working, and 95% effort to ensure it works under all circumstances, including network dropouts, etc. If you go here (http://www.csinnovations.com/framework_delphi.htm) you can see how I implemented my inter-process communications framework. The TCP stuff comprises about 10,000 lines of code using the Indy components.
I have a Client/Server application written Delphi. Essentially all the application is doing is transferring xml data streams between a server application and connected clients. I am currently using the Indy TIdTCPServer component. But the server side application keeps crashing on some of my installments. And it has been extremely difficult to debug. So I am wondering if there is some "architecture" I should be utilizing which does all the tcp/ip connection management and database connection pooling, allowing me to concentrate on the business logic.
Here are more details:
clients must maintain a "persistent" connection. There are times when the server must notify and send data to all connected clients.
clients are connecting from laptop computers using wireless aircards. So network "drops" are pretty common.
Backend database is SqlServer.
There can be upward of 100 computers simultaneously connected at a time.
When the server gets a new connection (TCPServer.OnConnect) I instantiate my own object containing it own SqlServer database connection. When tcp connections are dropped I in turn free these objects (and associated database connection).
Client application have a TTimer built into them. They routinely send heartbeats to the server. And if they "drop"/"lose" their connection they automatically establish a new connection once the network is back.
Anyone have any suggestions on the best approach/architecture here?
I presume the Indy component would work, but at the same time feel I am "reinventing the wheel" with respect to managing the connections.
Three component sets I am aware of that will take care of the nitty gritty technical aspects of client server applications for you:
kbmMW: http://components4developers.com/
Asta: http://www.astatech.com/index.asp
RemObjects: http://www.remobjects.com/
You may have to rework your applications to take advantage of the way these component sets work, but assuming you have properly separated layers that shouldn't be too much of a hassle and will buy you the advantage of well tested and widely used code for your client server work.
If you want some light TCP/IP components, take a look at our SynCrtSock unit.
You'll find low-level classes to create IP Client and Servers.
We implemented both TCP/IP and UDP/IP in one of our applications.
There is also a THttpServer class, which implement a HTTP/1.1 server. Therefore it follows the HTTP/1.1 connection management. There is also an optional compression, and using HTTP/1.1 on a port other than 80 is not a bad idea. And what is good with HTTP/1.1 is that it can pass through firewalls, and can be easily be VPNed or hosted on another HTTP server (like IIS or Apache) with a proxy. There is even a FastCGI class, if you need such a server under a linux-based solution.
Of course, a THttpClientSocket class does the same on the client class.
We use these classes to add HTTP/1.1 connection to our Open Source SQLite3 RESTful framework - http://synopse.info/forum/viewforum.php?id=2
See http://synopse.info/fossil/artifact?name=722e896e3d7aad1fe217b0e2e7903483e66d66d1 for the SynCrtSock unit. Open source, work from Delphi 7 to Delphi 2010.
Misha Charrett's CSI Application Framework covers pretty much exactly what you're asking for.
It's an open source Delphi framework that at its heart is a distributed message passing and threading framework that allows XML message passing from both client to server and server to client.
It can handle disconnections/reconnections, high client numbers and there's an optional virtual database library that will handle SQL server (or you could just use same SQL Server access you're using now).
It's not particularly well known yet but I can tell you that it's been actively developed over the last few years and that the author Misha is very keen to assist anyone who's interested in using it in their application.
Well, it would probably require a complete rewrite of much of your C/S code, but instead of using the Indy components, you could try to use a COM+ solution instead. Basically, you would create a COM+ component that will be installed on the server and your client applications will connect to this client and call the functions of this component directly. It will have transaction management which will be handled by Windows itself and the same is true about handling transactions. It's also technically possible to create events, which would allow the server to do callbacks to the client, although that would make things a bit more complicated.
I don't think this solution would work out for you, though, unless you have a lot of experience with COM development in Windows and/or you're brave enough to try something different.
In the past, I had a similar problem where hundreds of clients had to connect to a single server, doing all kinds of database transactions. It has a steep learning curve but me and my team managed to get things working and once we understood the technique, it resulted in a very stable and reliable solution which did manage to have up to 500 users simultaneously doing updates and other actions in a one-time extreme stress-test. But again, the learning curse is steep, so it might not be the solution you're looking for.
(Still, COM+ will use a lot of functionality that's build-in into Windows, like transaction management, database pooling and whatever more.)
If you use Indy each connection will equal a thread.
Anyway, I suggest for connecting to MSSQL to use SDAC from Devart http://www.devart.com/sdac/ and for the connection layer to use HPScktSrvr based on I/O Completion Port from http://www.torry.net/authorsmore.php?id=7131 (I don't know though what changes it will need for TThread changes in newer VCL).
You build your client class arround THPServerClient, you set your new class as the server ClientClass and the framework will create automatically new clients for you.
You may also want to have a look at the ICS/Midware combo: http://www.overbyte.be/