| Author |
Message
|
| Bullshit |
 Posted: Wed Mar 29, 2006 4:44 am Post subject: MQSeries vs. FTP |
 |
|
Guest
|
Hello,
i must compare MQSeries an FTP. Has somebody informations for me, wich can help me for this task?
I must find find Advantages and Disadvantages for each of the technics.
Thank you for help!
..and sorry for my bad Englisch... |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Mar 29, 2006 6:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Some points.
FTP is synchronous - it requires both ends to be available at the time of transmission.
MQ is asynchronous.
FTP has no connection or data retry logic built-in.
MQ can guarantee that a particular message arrives exactly once, no more no less.
FTP does not support SSL, although it can be run through an SSL tunnel or otherwise make use of SSL.
MQ has support for SSL built in.
FTP can send a single packet of data that is as large as you want it to be.
MQ can only send a single packet that is less than or equal to 104857600 bytes in length.
FTP is fairly sensitive to network speed and usage.
MQ is fairly insensitve to network speed and current usage.
In general, MQ can be very good for file transfer types of solutions. But it is much much better to buy a product that knows how to use MQ to do this than to try and build one yourself.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Tibor |
| Posted: Wed Mar 29, 2006 7:48 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
FTP - commonly simple administration
MQ - not trivial administration, in particular when you need large transfers |
|
| Back to top |
|
|
| sandiksk |
| Posted: Wed Mar 29, 2006 8:16 am Post subject: |
|
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
With FTP the following problems could occur:
the sending system might delete a file (message) when the sender thinks the receiver has received the file
the sending system might send multiple copies of a file to the receiver (over writing the originals)
the sending system might send messages out of order |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Mar 29, 2006 8:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
FTP the userid and password is sent in clear text with obvious security risks.
FTP access to files from programs is not transactional and needs to be serialised (lock out).
FTP is not CLUSTER aware and so cannot be managed with MSCS etc.
FTP the password cannot be changed using the FTP protocol.
FTP does not provide any restart/resume capability for interrupted transfer (no checkpoints).
FTP has no in-built ability to re-retry a file transfer if the other end is down.
FTP cannot ensure that the entire file has been sucessfully transfered.
FTP cannot perform conditional post-transfer processing automatically.
FTP does not work in a transactional mode (which would ensure data is sent once only).
FTP does not provide assured delivery, or confirmation of arrival.
FTP cannot ensure the integrity of the data being transmitted.
FTP in get mode allows unauthorised access attempts to the data.
FTP does not ensure record/message order (over more than one file).
FTP does not allow overlapping - eg processing records before they have finished being produced - MQ can reduce elapsed time.
FTP requires disk space to store a complete copy of data before and after transmission
FTP only has basic data conversion if any - no support for UNICODE etc.
FTP sends all the data in clear text, therefore introducing privacy issues.
FTP forces the use of batch windows and file based procedures.
FTP cannot ensure that the other end of the link is who they claim to be.
FTP only one program/thread can be reading a file, whereas multiple threads can be processing messages from a queue at the same time, exploiting multiple processors.
FTP does not have even the most basic built-in scheduling features.
FTP has no system management, tracking or control features for operations.
FTP usage often requires that online systems have downtime periods.
FTP in progress can't be cleanly cancelled in the event that the need arises.
FTP limitations usually result in considerable manual intervention and costs.
FTP does not offer compression of data which can be important for large volumes.
FTP inherently has major data latency whereas a messaging design might have almost none.
FTP has no central point of administration or control, so that operational and management effort increases with every deployment of an additional FTP transfer.
FTP embeds meta-data information such as user name, password, host name, file name making them awkward to change and, in the case of password, violating security policies when not changed.
FTP accidental or deliberate use of the wrong FTP password will cause failures in production by revoking ids. |
|
| Back to top |
|
|
| Bullshit |
| Posted: Sun Apr 02, 2006 9:25 pm Post subject: |
|
|
Guest
|
|
| Back to top |
|
|
| NSJ |
| Posted: Mon Apr 03, 2006 1:03 am Post subject: MQ Software |
|
|
Novice
Joined: 06 Jul 2005
Posts: 12
|
Hi
Just some info. I had a preview of a product from MQ Software which is especially designed for transferring large files across using WebSphere MQ. It would be worthwhile to have a look at it.
I think their product is called Data Flow Studio.
cheers
NSJ |
|
| Back to top |
|
|
| Bullshit |
| Posted: Mon Apr 17, 2006 4:31 am Post subject: |
|
|
Guest
|
Hello,
can someone say me the transferspeed from MQSeries and FTP?
What is faster? MQSeries or FTP? And how much Kb/s can FTP/MQSeries transfer?
I found nothin in the Internet over this...
Thank you for all your answers! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 17, 2006 4:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The answer to your speed question is "no faster than the network between the two end points".
Which is faster? That depends, a bit. You'll have to try it yourself and see what works best on your network and your location.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Mon Apr 17, 2006 9:39 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| I did a benchmark a long time ago between MQ V5.1 for AIX and OS/390. FTP will always outrun MQ, although MQ can get close in some situations, but that's the exception. I would be highly skeptical if anyone claims otherwise. |
|
| Back to top |
|
|
| sirsi |
| Posted: Mon Apr 17, 2006 2:09 pm Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
|
| Back to top |
|
|
| ashoon |
| Posted: Mon Apr 17, 2006 4:25 pm Post subject: I beg to differ |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
I did a test between Windows Copy, FTP and MQ on two windows machines and MQ was much quicker... 4.5 GB in 1 1/2 minutes compared to 4+ w/ FTP.
| rtsujimoto wrote: |
| I did a benchmark a long time ago between MQ V5.1 for AIX and OS/390. FTP will always outrun MQ, although MQ can get close in some situations, but that's the exception. I would be highly skeptical if anyone claims otherwise. |
|
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Tue Apr 18, 2006 6:41 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| Did you MQ process actually read a file, send the contents as messages and create a file on the other side? Receiving messages and having them stored in a queue is not the same as creating a new file. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 18, 2006 6:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There are huge performance differences between version 5.1 and even version 5.2 - and it just gets better as you move to version 6.
Yes, the MQ protocol is more complicated than the FTP protocol - so it should always run slower than the FTP protocol.
But the FTP protocol is more sensitive to the network usage than the MQ protocol.
A meaningful benchmark would have to take at least some steps to ensure that the network utilization between the two end-points was constant for both trials. This can be tough.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ashoon |
| Posted: Tue Apr 18, 2006 9:12 am Post subject: yep - did file to file |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
using pm4data and it was faster...
| rtsujimoto wrote: |
| Did you MQ process actually read a file, send the contents as messages and create a file on the other side? Receiving messages and having them stored in a queue is not the same as creating a new file. |
|
|
| Back to top |
|
|
|
|
