FileCatalyst » Fast File Transfer by FileCatalyst | http://www.filecatalyst.com Reinventing File Transfer Wed, 01 Feb 2012 22:35:57 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 FileCatalyst JavaScript API: In-Browser File Transfer http://www.filecatalyst.com/filecatalyst-javascript-api-in-browser-file-transfer/ http://www.filecatalyst.com/filecatalyst-javascript-api-in-browser-file-transfer/#comments Tue, 31 Jan 2012 19:32:04 +0000 Greg http://www.filecatalyst.com/?p=2763 Introduction

The FileCatalyst JavaScript API offers the ability to implement an accelerated file transfer application from within a web browser. Using the API, you are able to customize the end-user's file transfer experience, integrating the file transfer into your site (in terms of both functionality and UI) in a way not necessarily possible with the default configuration alone.

The Quick Version

If you just want to see how the API can be called, here's an example using jQuery:

$('#uploadButton').click(function() {
  document.FileCatalyst.uploadLive();
});

It's that easy. The API documentation gives a rundown of each of the methods available via JavaScript. Here, we have bound a click listener to some element with the ID "uploadButton". When that element is clicked, the JavaScript triggers the upload function of the applet.

Requirements

End user: JavaScript enabled on their browsers, Java installed on their machines (for the desktop environment, this is the vast majority of users)

Developer: 2 files that come with FileCatalyst; plus 2 custom components:

  1. Included: The applet script (ex. fcupload.js)
  2. Included: The applet JAR file (referenced by the applet script) (ex. FileCatalystApplets.jar)
  3. Custom: A webpage that will load the applet and provide controls (applets ship with sample pages to use as a starting point)
  4. Custom: Additional script(s)

Our Longer Example: Uploader with buttons

In this simple example, we have decided that we want to reduce the full-blown UI down to three key buttons: “Add to Queue”, “Upload”, and “Cancel”. In the following code samples, three important tasks are accomplished: 1. the applet is added to the page; 2. the applet's default UI is hidden; 3. our three buttons are hooked up using the FileCatalyst API and the jQuery JavaScript library.

The Webpage

Let's have a look at the webpage. In this case we're just using static HTML.

<html>
  <head>
    <title>FileCatalyst Upload with JavaScript API</title>
    <script src="http://code.jquery.com/jquery-1.7.1.min.js"></script> <!-- load jQuery from wherever you prefer -->
    <script src="uploadApp.js"></script> <!-- our custom script that handles button events etc. -->
  </head>
  <body>
    <div class="wrapper">
      <h1>Upload Sample</h1>
      <input id="browseButton" type=button class="fcbutton" value="Add to Queue" disabled="disabled"/>
      <input id="uploadButton" type=button class="fcbutton" value="Upload" disabled="disabled"/>
      <input id="cancelButton" type=button class="fcbutton" value="Cancel" disabled="disabled"/>
      <div id="fc_upload">
        <script src="fcupload.js"></script> <!-- The upload applet will load here -->
      </div>
    </div>
  </body>
</html>

In the <head> section, we have included jQuery (which we will use for event binding) and then our custom script (which will contain the event binding and any other JS functionality we may wish for). jQuery is possibly overkill if your page is literally as simple as this example; however, many people are already using jQuery on their site.

Buttons are simply <input> elements with type "button". The buttons also have the class "fcbutton" for convenience in styling and scripting. They are disabled by default, and will be enabled upon applet load. This has the added benefit of keeping the buttons disabled for users without JavaScript enabled on their browsers.

Adding the applet to any webpage couldn't be easier. Below the buttons we simply load the applet's JavaScript file with a <script> or <embed> element (depending on browser). Once loaded, the applet appears in the DOM inside an <applet> node.

Hiding the applet

Next, we need to hide the applet's default UI. You can do this with pure CSS using visibility: hidden, but NOT with display: none (which will not allow the applet to load). A safer bet is to use the height and width parameters inside fcupload.js, however. Setting these to zero will work in some but not all browsers. The safest bet is to make the applet tiny (1X1) and stick it somewhere on the page that's out of the way.

Inside fcupload.js, find these lines and modify as shown: 
// GUI Behaviours and Presentation
var width                       = "1";
var height                      = "1";
var background                  = "255,255,255"; //RGB value for white. You can make it the same color as the element it sits inside

// (later in file)
var callurlonload               = "javascript:appletLoaded()"; // this will trigger the JS "appletloaded" function

For additional insurance, you might have some CSS that hides the applet or takes it out of the document flow:

#fc_upload {
  position: absolute; /* remove from flow */
  visibility: hidden; /* optionally make it completely invisible */
}

Hooking Up the Buttons / Custom Scripts

This is the meat of the whole exercise. We are using jQuery for its simple syntax, but you can use whatever event-binding method you prefer (even inline onclick attributes). All we do in the script is bind a listener to each button. When the button is clicked, a JavaScript function from the FileCatalyst API (now available through the included applet) is fired.

Inside uploadApp.js (or whatever you have named your file):

function appletLoaded() {
  $('.fcbutton').removeAttr('disabled'); // the applet has loaded, so enable the buttons
}

/* bind the click events when the DOM is ready for scripting */

$(document).ready(function() {

  $('#browseButton').click(function() {
    document.FileCatalyst.browseLive(true);
  });

  $('#uploadButton').click(function() {
    document.FileCatalyst.uploadLive();
  });

  $('#cancelButton').click(function() {
    document.FileCatalyst.setCancelled();
  });
});

The appletLoaded function (referenced in fcupload.js modifications) removes the "disabled" attribute, enabling the buttons. The event handler listens for clicks on the buttons, and fires off a method call to the applet, using the available JavaScript functions.

Conclusion

Using a Java applet puts FileCatalyst right in the browser, with no installation required. Full acceleration and security options, without the end-user needing to configure anything is a big win for any organization that uses the web (and what organizations don't?). Our own API sits under our powerful Workflow and Webmail applications, but if you do not need a fully realized web portal out of the box, or are integrating FileCatalyst within your existing portal, the JavaScript API offers virtually every option you might need.

Transfer hook functions such as getTimeRemaining(), and getFilesSoFar() (along with a whopping 42 other useful hooks) allow you to capture information from an ongoing session. For the upload applet, functions such as the ones used in this post's example (along with another 20) allow you to invoke applet methods through JavaScript.

The potential is huge. Included in the FileCatalyst Upload Applet package is a sample of a web application that uses AJAX to fetch page content; the applet is never unloaded/destroyed (the way it would be when navigating to an entirely separate page), so you can have a transfer persisting while the user continues to explore the site. The sample uses a number of transfer hooks and upload applet methods, so look to it as a more sophisticated sample than the one provided in this exercise.

]]> http://www.filecatalyst.com/filecatalyst-javascript-api-in-browser-file-transfer/feed/ 0 Analysis On Improving Throughput Part 1: Disk IO http://www.filecatalyst.com/analysis-on-improving-throughput-part-1-disk-io/ http://www.filecatalyst.com/analysis-on-improving-throughput-part-1-disk-io/#comments Tue, 17 Jan 2012 21:34:54 +0000 Christian http://www.filecatalyst.com/?p=2750 In light of the release of FileCatalyst Direct v3.0, I thought I'd write a few articles about the road to achieving 10Gbps speeds. It seems to me the best place to start is with the endpoint of the transfer: the storage media. Why? Before we even think about the file transfer protocol, we have to be sure that our disks can keep up. It's very easy for people to forget how much of a bottleneck disk read & write IO can be.

Disk IO Tests

10Gbps (1250MB/s ) is fast. Especially for a single file stream. By comparison:

  • Your average enterprise HDD SATA drive will read/write between 50-100MB/s (or 800Mbps)
  • Your average SSD SATA drive will read data at 300MB/s, and write at 200MB/s (1.6 Gbps-2.4 Gbps)
  • FiberChannel SAN arrays normally connect between 500MB/s to 1000MB/s (4Gbps or 8Gbps)

Getting FileCatalyst to run 10Gbps speeds (1250 MB/s) requires testing your hardware infrastructure. Having a fiber SAN may not be enough.

For our internal test environment, this meant adding a few RAID 0 arrays (8 SSD drives or 16 HDD drives) in order to achieve the desired speeds. Certainly not mentioning this as a recommendation for a production solution, but it was the simplest way to achieve the speeds we needed for testing.

To determine what your system is capable of providing, FileCatalyst includes tools within FileCatalyst Server, HotFolder, and Command Line Client. The tools are command-line scripts designed to emulate how the FileCatalyst software manages Disk IO, and can give you a good approximation of your system's potential before a single byte has transferred over the network.

Running Enhanced Disk IO Tests

ReadIO and Write IO tests have a similar syntax to run them. ReadIO is executed by the executing the application switch "-testReadIO", while the write io uses the switch "-testIO". Since most issues are found with write speeds (which tend to be slower than read), let's focus on write IO.

The Write IO test creates a file on your file system, and reports back how quickly the file was created by the application. How it creates that file is determined by the parameters you must fill in before it runs:

<code>C:\Users\ccharette\Desktop\applettests\CL>java -jar FileCatalystCL.jar -testIO
Entering Write TestIO. This will run a series of tests on the file system to 
attempt to discover the optimal values for # of writer threads and write block 
size for your system.The test is both IO intensive and CPU intensive. Please 
give the test adequate time to complete.

Please enter the drive/path you wish to test (ie:  C:/ or /mnt/data/ ):  c:\temp
  File to be written:  c:\temp/test.io

Please enter the size of file you wish write (in MB, default 500):  10000
  File size:  10000MB.

Please enter the timeout length (secs) per run (default 60 secs): 180
  Timeout:  180 seconds.

Please enter the number of runs to perform for each settings (default 5): 3
  Number of runs per iteration:  3

Test if buffer size used in writes to disk affect performance.
Please enter a buffer array to attempt (default:  '64,128,256,512,1024,2048,4096')
Size in KB, comma delimited: 4,16,64,256,1024,4096,16384
  4 Buffer Size values (KB):  4,16,64,256,1024,4096,16384.

Test if multiple writters offer performance benefit when saving a block to disk.
Please enter a writer thread array to attempt (default:  '1,2,4,6,8'): 1,2
  2 Thread values:  1,2.

How many files would you like to create concurrently for IO test (default 1)?
Note:  number of files will never exceed number of writer threads during tests.
  1 files will be created in test:  1.

Test using Direct IO when allocating buffer space by Java (default true):  true
  Use DirectIO = true.

Mode used to open up files (rw/rws/rwd -- default rw):  rw
  Mode used = rw.</code>

Things to note:

  • It is better to create a file large enough that it represents your total data set expected for the transfer (ie: 9GB DVD ISO), or larger than the amount of memory the OS can utilize for file system buffers (see results below).
  • Timeout should represent a valid length of time you expect can easily be reached when writing a single copy of the file.
  • Specify # of runs with the average posted.
  • Buffer size represents an optional switch on the Server & Clients which dictates how large each read/write IO should be from the JAVA code down to the file system. You should experiment with a few values here, as different disk configurations sometimes yield vastly different optimal results.
  • The Server and Clients support multiple read and write threads per file.
  • Keep the # of files to create concurrently to 1 if you are testing only a single file tranfer speed (single client to server endpoint). This is actually one of the hardest test cases to manage, as there are OS level locks which often task the CPU, limiting throughput you can get when writing to a single file. If you are looking to test 10 clients each utilizing 1Gbps connection, select multiple files (much higher file IO possible when multiple files are being saved at a time).
  • Always select Direct IO, since this is what the FileCatalyst application uses.
  • Select default "rw" mode, which takes advantage of OS level memory buffers if available.

Results

Machine 1a: Windows 7, single SSD drive Machine 1b: Windows 7, single HDD drive 
Tests run with the following parameters:
        file:  c:/temp/test.io
        size:  10000000000
        timeout:  180000
        directIO:  true
        file mode:  rw
        Max # files to use:  1
  # of THREADS  |1      |2
Buffer size     +=======+=======+
4               |240    |150
16              |237    |150
64              |238    |150
256             |236    |152
1024            |237    |152
4096            |236    |149
16384           |236    |196
 
Tests run with the following parameters:
        file:  E:/tmp/test.io
        size:  10000000000
        timeout:  300000
        directIO:  true
        file mode:  rw
        Max # files to use:  1
  # of THREADS  |1      |2
Buffer size     +=======+=======+
4               |89     |52
16              |92     |53
64              |92     |53
256             |92     |53
1024            |95     |54
4096            |100    |55
16384           |104    |79
Machine 2a: Ubuntu RAID 0, 8 x SSD, 10GB file Machine 2b: Ubuntu RAID 0, 8 x SSD, 60GB file 
Tests run with the following parameters:
        file:  /opt/tmp//test.io
        size:  10000000000
        timeout:  60000
        directIO:  true
        file mode:  rw
        Max # files to use:  1
  # of THREADS  |1      |2
Buffer size     +=======+=======+
4               |1431   |1282
16              |1722   |1614
64              |2059   |1748
256             |2239   |1933
1024            |2095   |2050
4096            |2078   |2048
16384           |1841   |1720
 
Tests run with the following parameters:
        file:  /opt/tmp//test.io
        size:  60000000000
        timeout:  180000
        directIO:  true
        file mode:  rw
        Max # files to use:  1
  # of THREADS  |1      |2
Buffer size     +=======+=======+
4               |1093   |893
16              |1177   |1131
64              |1400   |1184
256             |1387   |1324
1024            |1402   |1303
4096            |1293   |1294
16384           |1140   |1271

Observations: Note that neither of these machines benefitted from multiple writer threads, and that performance was higher when a single writer was involved.

Machine 1a: When writing to SSD, we can get 230+ MB/s (>1.8Gbps) of write speed when using 1 thread. Block sizes do not affect throughput.

Machine 1b: Same machine, but utilizing slower secondary HDD drive. When using slower disks, the software can only get a fraction of the bandwidth (in this case < 1Gbps). We do see marginal improvements the larger the block size used, so limiting the block size is not a good idea. By default, the FileCatalyst application will use the largest block size it can (determined by UDP block size).

Machine 2a: Can read/write at 2000+MB/s (>16Gbps) for 10GB files. We can also see a sweet spot of ~256KB write block, where smaller writes adversely affect performance (as to larger blocks). This system however has 48GB of RAM on it, so the numbers it provides me are actually above what I would expect the system to give me.

Machine 2b: Same test, but with 60GB file. Now we have realistic numbers which match the disk IO, giving us a system capable of sustaining 1350MB/s (10.5Gbps) write speed.

Configuration Values

On the Server & Client side, the following configuration options are therefore available to set (CLI arguments shown):

  • numBlockWriters [#]
  • writeBufferSizeKB [# KB]
  • writeFileMode [rw/rwd/rws]
  • numBlockReaders [#]
  • readBufferSizeKB [# KB]

This are machine specific settings. To maximize performance, you need to run tests on both endpoints (client + server). On the server (if client connections are going to do both upload and downloads), you should run both read and write tests.

For both the FileCatalyst Server and HotFolder, these settings are configuration file changes that must be manually set (fcconf.conf for server, fchf.conf on HotFolder). For the CLI, these may be passed in as run-time arguments.

Conclusion

Knowing the limits of your system IO is the first required step in achieving high speed transfers. FileCatalyst v3.0 provides several tools to help both benchmarks those limits and tune the application to best take advantage of your system.

]]> http://www.filecatalyst.com/analysis-on-improving-throughput-part-1-disk-io/feed/ 0 What Problems are we solving? http://www.filecatalyst.com/what-problems-are-we-solving/ http://www.filecatalyst.com/what-problems-are-we-solving/#comments Fri, 23 Dec 2011 20:16:22 +0000 Greg http://www.filecatalyst.com/?p=2728 This blog post is in response to a Google+ topic presented here by Jay Cuthrell (@qthrul)

The question was:

I'm catching up on Aspera, Digital Rapids, FileCatalyst, Kencast, RepliWeb, RocketStream (TIBCO), Signiant, SmartJog, etc... What problems are each of these companies solving today? Tomorrow? Any other suggestions?

My response was an impromptu stream... written on the fly... and since Google+ wouldn't actually let me post it from my account (too long? thread locked?) I thought I would reproduce it here in this blog instead:

Hi Jay, good question. Some of the companies you mention (including the one I work for, FileCatalyst) are definitely interested in seeing businesses replace FTP for their file transfer needs. Some of our marketing materials even say, "FTP was born in the 70's... and you're still using it? Seriously?" I believe a few others are using FTP for transport, but adding a layer of management.

So my own short answer to the question is: FileCatalyst is trying to solve the problem of (primarily large, primarily high-speed) file transfer on WAN.

The broader answer would be an essay. And those who know me will say that I'm just the man to ramble a subject into the ground. But I'll try to keep it brief. My first disclaimer: I'm not an engineer for the company; if any of the information I present is in dispute, I can get clarification from smarter folks than me.

The RFC for the FTP spec didn't anticipate the huge files and fast speeds we face today. Being based on TCP, it had reliability as job #1 rather than efficiency (though its reliability model hasn't really held up either). And it performs well enough up to about 10Mbps without tuning. Until recently, that described most residential and even many business connections, so people were (and still are) more or less satisfied and didn't see the need to replace this absolutely ubiquitous technology (FTP). Sure there were other problems (reliability, ease-of-use, auditing/tracking) but people seemed more or less content to stick to FTP or at least FTP-based Managed File Transfer.

Larger enterprises and other businesses that have file transfer as a daily mission-critical task knew better, and were the first businesses to notice that even with shiny new 45Mbps connections (of course since then we've seen 100Mbps, then 1Gbps, and now 10Gbps connections becoming the 'shiny new' links) they weren't getting the speeds they expected and started looking for alternatives.

There were only a few of us at the time who had independently of one-another seen the possibilities UDP had to offer. UDP is only about a decade newer than TCP, truth be told. But it wasn't meant for file transfer because it had NO reliability built into it... it was meant for streaming and broadcasting. Adding the layer of reliability on top of UDP is what makes the file transfer protocols of FileCatalyst, Aspera, Signiant, and other peers unique. It's also what makes each of our solutions proprietary.

I'm still not answering the question directly, though, so I'll move on. I would like to add my second disclaimer which is that I'm trying to answer the question "what do we solve" and therefore answers will inherently look like marketing pieces. This is not my intention!

  1. For the enterprise, FileCatalyst is definitely solving the problem of large file transfer on high-speed networks. We're constantly pushing and testing the limits of FTP (as a 'competitor', we need to give it benefit of the doubt! And our technology can also "speak" TCP when needed) as well as the FileCatalyst protocol. TCP is inherently bottlenecked. It will never reach 10Gbps for transferring a large file. We are reaching those speeds on relatively modest single-space units, with encryption.
  2. FileCatalyst also solves reliability problems present in FTP. TCP's checksum model is archaic and unreliable, as anyone who has had a failed transfer can attest to. And most of us who transfer large files have also seen that it does not always reliably resume the transfer (and that's assuming resume is even enabled, which is not always the case). By contrast, we have a whole set of retry/resume facilities that ensure delivery of any size of file through any network conditions.
  3. Speaking of network conditions, this is the main thing that our technology (and other UDP-based technologies) solve. We're immune to latency and packet loss, adjust to network conditions, and recover any missing packets in a highly efficient manner (I can't speak for all of the UDP-based competitors, but we do not just blast packets willy-nilly and collect lost ones later-- the protocol tries to lose as few as possible in the first place).
  4. What differentiates each of the competitors is the feature set on top of the protocol. In other words, we also solve client-option and "management" problems in different ways. FileCatalyst offers too many management features to list here, but suffice it to say that you can adjust file transfers on the fly, collect and record transactional information and logs, be aware of when files are sent and to whom, and access an entire deployment via a central console on the web. There isn't much that you can't monitor and manage remotely, and since it may all be secured with SSL (and AES for data), you are able to meet security and compliance mandates.
  5. Another problem with FTP is the end-user experience. Those of us who are a bit more technical don't mind installing and configuring an FTP client, but remember that there are many people out there for whom using an FTP client feels like engaging in mysterious and forbidden arts. For those people we have a number of options that will get them transferring files in moments, some of which require zero installation or configuration while still allowing UDP-based transfers.

    6. I've lost most of your readers already, especially once the "marketing sounding" parts kicked in... but in short: every problem you can think of that FTP offers in terms of either technical problems or usability problems... we have solved or are trying our best to solve.

    Should I mention that people use email for file transfer, too? A whole other problem to be solved....

    What problems are we solving for tomorrow? In terms of the technology, we're always pushing for efficiency. We're going to turn the corner and 10Gbps won't be the top dog, it'll be 20Gbps... then 100.... and as long as our protocol remains efficient, we'll have a strategy for scaling. In terms of usability, there's always room for improvement or lateral thinking. How can we break down the barriers of adoption? How can people easily move from FTP to an alternative? As mobile devices become a primary mode of computing, how can we ensure a seamless experience in that space? I certainly have more questions on this one than answers. I wonder what other people see as being the file transfer problems of tomorrow?

    There's a lot of talk in the media right now about storage SPACE. And of course as a file transfer software company, we always read articles and think, "OK, you need space... but you also need to get your files there in a timely fashion!" A lot of companies are going to be faced with shipping physical media to their cloud storage provider. We have solutions already, but people are still shipping discs or using FTP/HTTP. This is one of the problems of today that we'll also be solving for tomorrow.

    ]]> http://www.filecatalyst.com/what-problems-are-we-solving/feed/ 1 The World is Getting Faster – FTP is not http://www.filecatalyst.com/the-world-is-getting-faster-ftp-is-not/ http://www.filecatalyst.com/the-world-is-getting-faster-ftp-is-not/#comments Thu, 03 Nov 2011 20:20:52 +0000 Greg http://www.filecatalyst.com/?p=2676 Just finished reading a post at GigaOm regarding gigabit fibre in the UK.

    Of course, being in the business that we're in, I immediately thought: if businesses of all sizes, and even homes end up with 300Mbps connections (or faster), what are all these people going to be doing to transfer their large files? Home users and those who don't know there are options are still going to be using FTP, and wondering why their file is taking so long to send. Typically, even with a good connection, FTP (or any transfer based on TCP) is going to start performing poorly at a measly 10Mbps. Under near-perfect conditions, a single-threaded FTP transfer is likely to reach 70Mbps tops. And when you're transferring from one part of the world to another, you do not have near-perfect conditions.

    Multi-threaded TCP (a technique FileCatalyst itself uses for certain scenarios) can help, but at the cost of resources. It doesn't take long for multiple TCP threads to slow down even a modern machine.

    Even if we forget about reliability (FTP having a poor track record is already a good reason to switch to something else) and other file transfer must-haves for a second, and we're right on the cusp of every file transfer process in the world needing something better. UDP-based file transfer like that offered by FileCatalyst and a handful of other companies will be the best alternative.

    At Gbps+ speeds, there's another bottleneck: I/O (how fast your network and storage can read or write), but that's a conversation for another day.

    Suffice it to say, when it becomes apparent to the world at large (people other than enterprises that have already switched) that FTP is just not working or is highly ineffecient, well-engineered UDP-based file transfer has already been created and is just waiting for the call.

    ]]>     http://www.filecatalyst.com/the-world-is-getting-faster-ftp-is-not/feed/ 0     FileCatalyst at GTEC 2011 http://www.filecatalyst.com/filecatalyst-at-gtec-2011/ http://www.filecatalyst.com/filecatalyst-at-gtec-2011/#comments Tue, 11 Oct 2011 14:58:37 +0000 Greg http://www.filecatalyst.com/?p=2661 GTEC is Canada's government technology event. Thousands of visitors from both the public and private sectors will be at GTEC to learn about the technologies at play within the government, as well as emerging technologies which may soon become a part of the government's technology landscape. FileCatalyst has been deployed in a number of government scenarios in Canada and abroad. GTEC presents the perfect opportunity to showcase what we are already doing, and what our technology can do for any governmental agency.

    From October 17 to 20, we will be at GTEC in Ottawa, Canada, on the 3rd floor of the Ottawa Convention Centre. We look forward to seeing you there!

    From the GTEC website:

    For 18 years GTEC (Government Technology Exhibition and Conference) has been inspiring public sector IT professionals with thought provoking demonstrations of advanced technology and a powerful line-up of speakers that features the best and brightest industry leaders. GTEC is Canada's Government Technology Event, and one which attracts over 7000 participants, renowned speakers, and exhibitors from across Canada and around the world annually. The event offers something for everyone: from CIOs and ADMs to Program Managers and IT personnel. All come to meet and network with peers, celebrate technology accomplishments, learn from a "who's who" of key note speakers, and see demonstrations of the most advanced technologies that are driving public sector IT initiatives at all levels of government in Canada and other countries.
    ]]>     http://www.filecatalyst.com/filecatalyst-at-gtec-2011/feed/ 0     FileCatalyst at InterOp NY 2011 http://www.filecatalyst.com/interop-ny-2011/ http://www.filecatalyst.com/interop-ny-2011/#comments Fri, 23 Sep 2011 19:20:18 +0000 Greg http://www.filecatalyst.com/?p=2642 FileCatalyst will be in New York at the Javits Centre from Oct 3–7, showcasing the lastest advances in our technology. Come visit us at booth 603 and we'll be happy to answer all your questions or provide a demonstration.

    While showing our technology, we will be focusing specifically on:

    • 10 Gbps transfers in the Enterprise. FileCatalyst is the first acceleration solution to reach these speeds.
    • The impending release of FileCatalyst Direct 3.0, with better performance than ever, and a new web-based management console.
    • The latest versions of our FileCatalyst web-based products, Webmail and Workflow
    • Monitoring and Management for mobile devices

    We hope to see you there!

    ]]>     http://www.filecatalyst.com/interop-ny-2011/feed/ 0     FileCatalyst 3.0 announced http://www.filecatalyst.com/filecatalyst-3-0-announced/ http://www.filecatalyst.com/filecatalyst-3-0-announced/#comments Fri, 23 Sep 2011 15:48:42 +0000 John http://www.filecatalyst.com/?p=2621 The new version can transfer files really really fast... up-to 10Gbps (1,250 MB/sec) with AES encryption! It also includes a global monitoring console to watch your entire file transfer Eco-system from a single browser window.

    You can read more about FileCatalyst 3.0 from: PR WEB

    Also you can watch this great YouTube video illustrating 10Gbps file transfer:



    ]]>     http://www.filecatalyst.com/filecatalyst-3-0-announced/feed/ 0     The Road To Banff leads through the Cloud http://www.filecatalyst.com/the-road-to-banff-leads-through-the-cloud/ http://www.filecatalyst.com/the-road-to-banff-leads-through-the-cloud/#comments Tue, 13 Sep 2011 18:41:17 +0000 Greg http://www.filecatalyst.com/?p=2599 Recently, FileCatalyst had a great opportunity to be a part of Canada 3.0, a digital media forum with over 2,000 participants discussing and shaping Canada's digital landscape.

    One of the events was a “pitch off” that saw participants exchanging large digital media assets. FileCatalyst provided the transport technology, which was deployed to a cloud solution provided by Canadian Cloud Computing. Deployment was quick, and the results exceeded all expectations.

    Read the case study “The Road to Banff leads through the Cloud“ in its original form at CCC's website.

    ]]>     http://www.filecatalyst.com/the-road-to-banff-leads-through-the-cloud/feed/ 0     FileCatalyst at GTEC this October http://www.filecatalyst.com/filecatalyst-at-gtec-this-october/ http://www.filecatalyst.com/filecatalyst-at-gtec-this-october/#comments Thu, 25 Aug 2011 15:04:51 +0000 John http://www.filecatalyst.com/?p=2568 GTEC is Canada's biggest “technology in the government” expo. With a number of government and military deployments under our belt at both Canadian and International level, we felt the time was right to show our leading fast file transfer technology to a broader public service audience, and GTEC was the obvious choice. Come and visit booth 301 on Oct 18th and 19th 9:30–4:30pm. The FileCatalyst booth will be located on the 3rd Level at Ottawa Convention Center in Ottawa, Canada.]]> http://www.filecatalyst.com/filecatalyst-at-gtec-this-october/feed/ 0 FileCatalyst at IBC http://www.filecatalyst.com/filecatalyst-at-ibc/ http://www.filecatalyst.com/filecatalyst-at-ibc/#comments Fri, 22 Jul 2011 15:12:55 +0000 Greg http://www.filecatalyst.com/?p=2536 At the time of this post, IBC is still a number of weeks away. However, preparations have been underway for several months already, and the date will be upon us before we know it!

    Since the last show, there have been major iterations of all our software, including the well-anticipated release of FileCatalyst Direct 3.0 and FileCatalyst Workflow 4.6.1. As our user base can tell you, we are continually improving our software; at IBC we will be demonstrating the latest versions of our current offerings, along with a few new surprises.

    The conference portion of IBC (International Broadcasting Convention) runs from September 8–13, with the Exhibition running from September 9–13.

    ]]>     http://www.filecatalyst.com/filecatalyst-at-ibc/feed/ 0