Difference between revisions of "Slicer/Features/Middleware"
From Slicer Wiki
(→Links) |
|||
| Line 1: | Line 1: | ||
| − | + | [[Slicer/Features]] | |
| − | + | For updates see [http://www.na-mic.org/Wiki/index.php/OpenIGTLink OpenIGTLink] | |
Latest revision as of 16:09, 19 May 2008
Home < Slicer < Features < Middleware
For updates see OpenIGTLink
Contents
Title
Middleware
Names
- session leader
- participants
Technology/Function description
Goal
- Slicer + IGSTK
Technologies
- Look at Publish subscribe ORB/ACE - DDS [Peter]
- Socket IGSTK [Junichi Patrick]
- Navitrack - phase out?
- Hard to debug
- Not modular (some modules can't be disabled)
- No error handling - just halt
- Not as simple and clean as just using the standard TCP/IP socket
- Still problems with image transfer under Windows and possibly other OS (packet size is not based on the size allowed by OS)
- Security: can be flooded with packets, no authentication
Requirements
- Reliable for command transfer (all data transferred, in order)
- Fast for tracking data transfer (only the latest coordinate is required, can lose data)
- Image transfer (500K or more)
- Data types (struct: string, integer, float)
- Data type checking (number is correctly formatted etc)
- Time out (device is down)
Would be nice to have
- Priority
- Point - multi-point data transfer
Questions
- UDP - fast, no delay due to ACK packages
- TCP/IP - reliable, easy
- Security
- malicious packets or sent by mistake
- CRC and auth.?
- pop up a dialog box before accepting data? (just one, to avoid flood)
- same issues with Slicer3:Slicer_Daemon
- Firewall?
See also
Potential application in IGT
- Tracker data transfer
- Image transfer from MRI
- Robot coordinate transfer
- Robot control
- Periferials: OpenTracker/Navitrack has 3D mouse driver etc.
Which part is already in Slicer
- IGSTK intra process communication
What is not
- IGSTK inter-process communication
Who among us will take leading role?
- Junichi
- Georgetown
- JHU
- Queen's
