Which one is (TCP/UDP) best to send files from Client to Remote server using Internet? i.e Which one is fast & reliable of my following requirement.
I have two requirements basically
1. Sending Files from Client to Server (Daily Once)
2. In Client system running one software, its having different product information,
latest packet Time, Product Status, etc .
This information is updated every one second.
My problem is, To know the Client status at server.
I am not able to decided which design is best of my requirement. They are
A.Using TIdTCPClient & TIdTCPServer
B.Using TIdTCPClient & TIdCmdTCPServer
C.Using TIdCmdClient & TIdTCPServer
D.Using TIdCmdClient & TIdCMDTCPServer
Please guide to me which design is best & how to implement it with example.
TCP/IP is slower but it assures you that you don't lose any packet without implementing that in your application
UDP is faster but you don't have the guarantee that the packet will arrive and you must implement some sort of confirmation
In your situation i think TCP is the best and TIdTCPClient with TIdTCPServer will do the trick.
Post some code if you get stuck.
Related
I want to implement a demo application to listen data via TCP/IP.
Data Transmitter will transmit a series or ASCII char or a series of string all the time. It feeds data into TCP/IP address (eg. 127.0.0.1:22) This could be a GPS transmitter.
I want to implement a demo application for receiving data by clicking the start button and listening to the data via TCP/IP and display it accordingly.
Correct me if I am wrong, I don't think I can use Server/Client server for this purpose. I tried to create a client application with TIdTcpClient, it receives only one time data. I don't think Indy has a TCP listening component.
Thanks in advance.
If you wanna monitor network comunications between some device and some other program on your computer using of TIdTCPServer won't work. Why? Once Indy will read network data it will mark it as processed and delete it from network buffer. So that data probably won't even reach to the other program on your computer. Workaround for this is that you design your application to actually work similar as network bridge. Your application listens to the data on one port and then forwards that data on another port on which the other program is listening. But the main problem is that you have to make this to work both ways.
What you need is somekind of a component which is able to peek at the network data but don't interact with it. This is usually done on driver level.
Now if it is not abolutely necessary to have such functionality in your own software but you are only interested in getting the data I recomend you try Wireshark (http://www.wireshark.org/). Wireshark is a verry powerfull freware software which alows you to monitor all netwrok traffic on basically all protocols without causing any interuptions. In order for this software to work it instals special driver which serves for intercepting the network data.
Maybe you would want to use same driver in your application if this functionality needs to be in your application.
Based on your diagram I think that your implementation could also be based on a message-oriented middleware, using a message broker which receives the GPS transmitter or other data.
The message broker would then store the data internally and forward it to all interested clients which are connected. A typical messaging pattern in this case is a "Topic", which broadcasts the messages similar to a radio station.
So the middleware will ensure that the information will be collected (optionally also persisted to disk) and then guarantees the delivery to the receivers. This can be done even in a way where receivers which have been off-line for a while still receive the GPS messages created while they where not listening ('retroactive consumers').
There are many popular free open source message brokers, and most of them also can be used with Delphi.
I have a server application that receives some special TCP packet from a client and needs to react to it as soon as possible by sending an high-level ACK to the client (the TCP ACK won't suite my needs).
However, this server is really network intensive and sometimes the packet will take too long to be sent (like 200ms in a local network, when a simple server application can send it in less than 1ms).
Is there a way to mark this packet with a high-priority tag or something like that in Delphi? Or maybe with the Win32 API?
Thanks in advance.
EDIT
Thanks for all the answers so far. I'll add some details. My product has the following setup: there are several devices that are built upon vehicles with WIFI conectivity. When they arrive at the garage, those device connect to my server and start to transmit data.
Because of hardware limitations, I implemented a high-level ACK to make the device aware that the last packet arrived successfully (please, don't argue about this - the data may be broken even if I got a correct TCP ACK). However, if I use my server software, that communicates with a remote database, to issue this ACK, I get very long delay (>200ms). If I use an exclusive software to do this task, I get small latencies (<1ms). So, I was imagining if I could just tell Windows to send those special packets first, as it seems to me that this package is getting delayed so the database ones can get delivered.
That's the motivation behind my question.
EDIT 2
As requested: this is legacy software and I'm using the legacy dclsockets140.bpl package and Delphi 2010 (14.0.3593.25826).
IMO it is very difficult to realize this. there are a lot of equipment and software involved. first of all, if you communicate between 2 different OS's you got a latency. second, soft and hard firewalls, antiviruses, everything is filtering/delaying your package.
you can try also to 'hack' the system(this involve some very good knowledge on how the frames/segments are packed/send,flow control,congestion,etc), either by altering it from code, either by using some tools like http://half-open.com/ or others.
In short, passing MSG_OOB flag to the send function marks the data as "urgent". Detailed discussion about the OOB in the context of Windows Sockets implementation specifics is available here.
I am using TIdCmdTCPClient and TIdCmdTCPServer. Suddenly I find that I might like to have bi-directional communication.
What would be best? Should I possibly use some other components? If so, which? Or should I kludge and have the 'client' poll the 'server' to ask if it wishes to communciate anything?
This is a very small system. Two clients and ten servers, with a burst of one tarnscation every 30 to 60 seconds for a few minutes once a day, so overhead for polling is inconsequential.
I'm just woder if there is a 'correct' way.
Update: this really is an incredibly simple system. Very little traffic and all of it simple. All transmissions are an indication of even type an an optional single parameter.
<event type> [ <parameter>] e.g. "HERE_IS_SOME_DATA 42"
This can be sent in both directions, hover here is no "reply" as such. Just fire off a message (and hope that it got there)? Receive an Ack with no data? Non-catching of an exception indicates that message was successfully sent?)
Would it be possible (would it be overkill) to use two TIdCmdTCPServer?
Both TIdCmdTCPClient and TIdCmdTCPServer continuously poll their socket endpoints for inbound data during the lifetime of the connection. You do not have to do anything extra for that. So, as soon as a TIdCmdTCPClient connects to the TIdCmdTCPServer, both components will initially be in a reading state until one of them sends a command to the other.
Now, there is a problem with doing that - as soon as either component sends that first command, the receiving component will interpret it as a command and send back a reply, which the other component will interpret as a command and send back a reply, which will be interpretted as a command and send back a reply, and so on, causing an endless cycle of replies back and forth. For that reason, it is not wise to use TIdCmdTCPClient and TIdCmdTCPServer together. You should either use TIdTCPClient with TIdCmdTCPServer, or use TIdCmdTCPClient with TIdTCPServer. Depending on what exactly your protocol looks like, you may have to forgo using TIdCmdTCPClient and TIdCmdTCPServer altogether and just use TIdTCPClient with TIdTCPServer so you have more control over reading and writing on both ends. It is hard to answer with actual code without first knowing what the communication protocol should look like.
A single TCP socket connection can be used in two directions. The server can send data asynchronously to the client at any time. It is up to the client however to read the socket, for asynchronous processing this is done in a listener thread which reads from the socket and synchronizes incoming data operations with the main worker thread.
An example use case in the Indy components is the Telnet client component (TIdTelnet) which has a receive thread listening for server messages.
But you also asked about the 'correct' way - and then the answer depends on other factors such as network stability, guaranteed delivery and how to handle temporary server outages. In enterprise environments, one central messaging hub is preferred in many use cases, so that all parties connect only to this central server which is only responsible for reliable message delivery, and keeps messages until the recipient is available.
You can download the INDY 10 TCP server demo sample code here.
I have over 50 clients connected to one server (low end server, running windows 2003 server), every time there is a power failure or switch failure the clients will disconnect from the server, the server might remain on during this incidents (if power backup is installed), when the clients came back they automatically detect the server and initiate a connection procedure, at this point the server will start dishing out the relevant data to the clients. Its at this point you realize some clients will start freezing becouse the server is not quick enough to dish out data and so it blocks the rest of the clients.
I have implemented a crude method to control this client storm but i was asking if guys out there have better algorithms to perform this kind of task.
NB: Am using Asta sockets components on a delphi application, but i dont mind examples from different fields,
Similar to network collision-detection protocols, perhaps clients could wait a random period of time before initiating their connection at startup?
In addition to the random startup delay suggested by Bremen, implement some sort of "too busy; try again later" message in your protocol. Rejecting a client with a short message should not be a problem for 50, 100, or even 1000 clients. Have the clients respond by doing a random delay and retrying + exponential backoff.
The solution depends on your preferences as well. Is it ok for you to drop down the connections request or send busy message?
Another option can be that you start sending data to the clients in sort of roundrobin manner. To this end you can have different threads responsible for sending data to different clients. Advantage of this case can be that none of the clients will be starved.
I have a classic client/server (fat client and database) program written in Delphi 2006. When certain conditions are met in the client, I need to notify all the other clients very quickly. Up until now this has been done using UDP broadcasts, but this is no longer viable as clients now connect from outside the LAN and the UDP broadcast is limited to the local network.
I'm aware of the Indy libraries but am not really sure of which components to use and how to structure it. I'm guessing I'll need to have a server that the clients connect to which will receive and distribute the messages...? Any samples out there to get me started?
Are there any other component sets or technologies I should look at instead/as well?
The simple answer is that the standard protocols available in Delphi (and other tools) don't allow for notification in reverse. I looked into this for a project where I wanted to use SOAP. They all assume client asks server, server responds and that's it.
For me, the solution was the RemObjects SDK. This allows you to send notifications to clients, and the notification can have any data you like (just like the client to server). Myself I use the SuperTCP connection, but it works with others too. It can still offer a SOAP interface for clients that must use it, but for where you have control of both client and server it works extremely well.
There are a few really easy ways to do this with Delphi, although I am sure the RemObjects SDK works really well too.
Have a central server that has a * TIdTCPServer listening* on it. Then each client has a TIdTCPClient on it. They connect to the server and block on a read waiting for the server to write. Once the server receives a notification via a listening socket it broadcasts to each of the waiting clients. This is pretty much immediate notification of all the clients.
Have a central server that has a TIdTCPServer listening on it. Then each client has a TIdTCPClient on it. Those clients can "ping" the server to ask for updates at a regular interval (use a session token to maintain state). The frequency of the interval determines how quick the notification will be. When once one of the clients needs to notify the others, it just notifies the server. The server then uses a message queue to make a list of all active client sessions and adds a notification for each. Then the next time each of the clients connects it gives it the notification and remove it from the queue.
Maintain a session table in the database where each client updates regularly that they have an active session, and removes itself when it disconnects. You will need a maintenance process that removes dead sessions. Then you have a message queue table that a client can write an update to with one row for each current active session. Then the other clients can regularly ping that table to see if there are any pending notifications for its session, if there are it can read them, act on them and then remove them.
Some sort of peer to peer approach were the clients are aware of each other through information in the database and then they connect directly to each other and notify or ask for notifications (depending on firewall and NAT configurations). A little more complex, but possible.
Obviously the choice of implementation will depend on your setup and needs. Tunning will be necessary to achieve the best results.
The components you need for this are the TIdTCPServer (listener) and TIdTCPClient (sender). Both of which are in the Indy libraries in Delphi.
ICS components from http://www.overbyte.be are great.
a.) Better compatibility than Indy
b.) PostCard ware
Good examples and support. Use TClientSocket and TServerSocket
FirebirdSQL project use the concept of notifications as being server-client connections that send a string to the client. For this, the db server uses an other port. And require the client to register it's interesting of receiving a certain type of notification through an API call.
You could use the same idea.
RabbitMQ should fit your bill. The server is free and ready to use. You just need a client side to connect, push/send out message and get/pull notified message
Server: http://www.rabbitmq.com/download.html
Do a google for client or implement yourself
Cheers
You should be able to use Multicast UDP for the same purpose. The only difference will be to join the multicast group from every client.
http://en.wikipedia.org/wiki/IP_Multicast
http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol
Edit: Just to clarify, multicast let you join a given "group" associated to a multicast ip address. Any packet sent to that address will reach every client who has join the group
You can watch weonlydo wodVPN component which permit you to create a robust UDP hole punching and gain a port-forwading or a normal VPN (with a fornished network adapter) so you can connect two PC behind a NAT.
I'm using this control for our communication program and works very fine.