MantisBT - VTK | |||||
| View Issue Details | |||||
| 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 | ||||
| Project | |||||
| Type | |||||
| 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/ [^] | ||||
| Steps To Reproduce | |||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| 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 | ||
| Notes | |||||
|
|
|||||
|
|
||||