| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0001890 | VTK | (No Category) | public | 2005-05-26 10:49 | 2016-08-12 09:54 | ||||
| Reporter | Luke West | ||||||||
| Assigned To | Berk Geveci | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | moved | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0001890: vtkSocketCommunicator byteswapping on re-connection | ||||||||
| Description | When using vtkSocketCommunicator between architectures of differing endian-ness, vtkSocketCommunicator correctly calculates the SwapBytesInReceivedData flag. But only first time around. If ->CloseConnection() is invoked, and a subsequent connection established with ->ConnectTo() or ->WaitForConnection(), there exists an intermittent byteswapping bug, and the reason is as follows... The penultimate statement of ->ConnectTo() is... if ( serverIsBE != IAmBE ) { this->SwapBytesInReceivedData = 1; } Note that this->SwapBytesInReceivedData is undefined if the condition is unmet! Similarly, the penultimate statement in ->WaitForConnection() is... if ( clientIsBE != IAmBE ) { this->SwapBytesInReceivedData = 1; } } Again, this will not reset the flag when the condition is unmet, and subsequent receive calls may swap bytes erroneously, depending on the value of ->SwapBytesInReceivedData during the previous connected state. One patch would be to append something like... else { this->SwapBytesInReceivedData = 0; } to both of the above conditions in each of the two Connect methods, and another solution would be to insert something like... this->SwapBytesInReceivedData = 0; in the ->CloseConnection() method. As always, arguments exist for adopting either (or indeed both) solutions, but in keeping with the style and treatment of the other state variables in the class (->Socket, and ->IsConnected, in particular), I would suggest the latter. So for clarity... I suggest inserting a single line to the ->CloseConnection() method in file vtkSocketCommunicator.cxx so the definition reads as follows... void vtkSocketCommunicator::CloseConnection() { if ( this->IsConnected ) { vtkCloseSocketMacro(this->Socket); this->Socket = -1; this->IsConnected = 0; this->SwapBytesInReceivedData = 0; // NEW! } } Many thanks for all your help, Luke J West : e-Science Research Assistant --------------------------------------------- Room 566/12, School of Ocean & Earth Sciences Southampton Oceanography Centre, Southampton SO14 3ZH United Kingdom --------------------------------------------- Tel: +44 23 8059 4801 Fax: +44 23 8059 3052 Mob: +44 79 6107 4783 Skype: ljwest --------------------------------------------- http://godiva.noc.soton.ac.uk/ [^] | ||||||||
| Tags | No tags attached. | ||||||||
| Project | |||||||||
| Type | |||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0036788) Kitware Robot (administrator) 2016-08-12 09:54 |
Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2011-06-16 13:11 | Zack Galbreath | Category | => (No Category) |
| 2016-08-12 09:54 | Kitware Robot | Note Added: 0036788 | |
| 2016-08-12 09:54 | Kitware Robot | Status | expired => closed |
| 2016-08-12 09:54 | Kitware Robot | Resolution | open => moved |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |