Pages: [1]   Go Down
  Print  
Author Topic: TCP based Bulk Data Transfer  (Read 4773 times)
November 05, 2012, 08:58:21 am
I'm working on a new plug-in "TCP". This custom channel will allow you to transfer any Quest3D bases Data Structures of arbitrary size between applications. With that I mean Text, Textures, Videos, 3D Object Data etc. To be more specific: Anything that can be put into a Buffer or Text channel.

The screenshots below show the transfer of video and 3D Object Data. Note, that the receiving application had no previous knowledge or access of the content. The size of the tree trunk is about 3 MB.

More technical details: The new TCP channel  can act both as a server or a client. Peer applications are either Quest3D applications, or any  program that handles TCP connections. In the latter case some restrictions apply: Here the maximum data size will be restricted to about 1 KB. Copying Quest3D channel content into Buffer channels and back is done by SaveChannelToBuffer and  LoadBufferIntoChannel. Video transfer is merely bound by the computing power of the peer machines and by the network bandwidth. Don't expect a full fledged video streaming solution.


* TCP-3DobjectData-screenshot.png (192.68 KB, 633x315 - viewed 911 times.)

* TCP-video-screenshot.png (137.64 KB, 633x316 - viewed 1062 times.)
November 07, 2012, 12:49:21 pm
A video is available now. The screenshot below shows the live transmission of a rendered scene.


* live-rendering-transmission.png (108.92 KB, 633x316 - viewed 861 times.)
November 15, 2012, 01:50:56 am
Great plug-ins, and look forward to  Grin
November 16, 2012, 12:17:22 pm
Nice work. What is the actual usage for this?

ali-rahimi.net
November 18, 2012, 11:27:55 am
Some thoughts about application scenarios:

1) Connect any external program or utility that is capable of TCP connections (either as Server or as Client) to your Quest3D application. This includes Flash applications with XMLsocket. Previous forums posts addressed these topics. The requirements are: Data structures must be compatible. A typical, robust example would be a CSV encoded text, which can be easily decoded by a TextFilter channel. Encoding of CSV inside Quest3D is done with TextOperator channels. Another encoding approach is XML. Other encoding schemes would require a dedicated new additional plug-in exchanging data with a buffer channel. The new TCP channel is a replacement for the following legacy channels: SocketString (included in some Quest3D versions), and the custom plug-ins TCPserverText and TCPclientText.

2) Transfer of data of arbitrary size between multiple Quest3D applications. This includes workload distribution, remote control, or collaborate applications. If the bandwidth and latency allows, even remote rendering or video chats are feasible (I did not check audio transport yet). The requirements are: Any channel content that can be mapped into a buffer is transportable via the TCP channel and is exactly replicated on the receiving side.
November 18, 2012, 11:54:52 am
Sounds great. I am more interested of having some sorts of stream mesh data for things like terrain, without any freezing. one possibility is to use XML and rebuild the mesh every frame, but that needs a huge xml and might not be practical at all. So i was wondering about the any possibility's like that.

ali-rahimi.net
November 18, 2012, 06:28:21 pm
See the attachments for a trial version of TCP.dll (4.3.2), the complete Manual, and sample files. Feel free to test the exe. The TCPbulkDemo.cgr is available to customers only. See my web pages to get the full version.

The limitations of the trial dll are listed in the debug window upon start up. Be aware, that video transfer requires lots of resources, use your local machine or a LAN in the beginning.

Edit (2014-06-02): All attachments moved to here. Look for TCP (trials are available for dll, cgr, and exe). Feel free to download and try.
May 27, 2013, 09:45:54 pm
Cant receive plain text from a server in Quest3D5 x64 and Hercules.

- send to a client = OK
- receive from a client = OK
- send to a server = OK
- receive from a server = Nothing

Probable I miss some detail.
Any example ?
May 29, 2013, 05:35:17 pm
NO problem at all .

Its just too fast to see the screen updated on a cycle.
A log of all transactions show me that messages are sent and received on both modes (when acting as client or server).

Really nice channel....
July 11, 2013, 06:02:12 pm
Updated trial material is now available [here].
January 09, 2014, 12:44:31 pm
Maintenance update published. Trials and manuals updated here.

Edit (2014-06-02) TCP.dll trial updated
August 25, 2015, 08:14:42 am
Tested on Win10. Success.
Pages: [1]   Go Down
  Print  
 
Jump to: