VxWorks TCP socket ref.

http://www.ee.usyd.edu.au/tutorials/tornado/vxworks/netguide/c-sockets.html

Although the socket interface is compatible with VxWorks, the environment does affect how you use sockets. Specifically, the globally accessible file descriptors available in the task-independent address space of VxWorks require that you take extra precautions when closing a file descriptor.



You must make sure that one task does not close the file descriptor on which another task is pending during an accept( ). Although the accept( ) on the closed file descriptor sometimes returns with an error, the accept( ) can also fail to return at all. Thus, if you need to be able to close a socket connection's file descriptor asynchronously, you may need to set up a semaphore-based locking mechanism that prevents the close while an accept( ) is pending on the file descriptor.

>> TCP  소켓과 파일 디스크립터가 공유된다는 언급.  따라서 주의해서 사용해야 할 것을 말함.
 TCP 소켓과 파일 IO가 RT 연결끊김에 연관관계가 있음을 의미

[Labview 8.6] sbRIO TCP/IP 연결끊김 문제

TCP 연결 사용시 cRIO 다운
http://forums.ni.com/t5/LabVIEW/Crio-Ethernet-Port-Crashes-Error-42/td-p/961070
 - 2009.08.10, LV861

1. cRIO9014가 TCP 연결에서 42번 에러를 발생하는 경우에 대한 실험
  1) TCP open과 TCP close를 연속으로 두고 100ms 주기로 실행시킨 후
  2) 케이블을 빼고 5초후 다시 연결하면 42번 에러 발생

2. CAR #141011으로 NI에서 대응중
  - ping.vi를 사용해보라고 하지만 잘 되지 않음

3. (간단 해결책) Timed Loop 안에 TCP 함수를 두지 말 것



TCP 연결 사용시 cRIO 다운(2)
http://forums.ni.com/t5/LabVIEW/cRIO-disconnects-from-Ethernet-network-and-stops-responding-to/m-p/754839
 - 2008.08.06

1. cRIO 9014 프로그램 로직 설명
 FPGA로 데이터를 수집하는 루프와 전송을 TCP 루프(5초 주기 재시도)가 있음
 cRIO는 주기적으로 이더넷 연결을 끊음
 56번 timeout 에러를 보이다가 어떤 경우에 TCP 복구가 되지않음
 랩탑에 직접 연결하여 실험할때는 수분내에 확인되나
 이더넷 스위치를 통해 다른 서버에 연결될때에는 수시간이 소요됨
 TCP 에러가 발생한 시점에도 이더넷 포트의 LED는 연결되었음을 보여줌(오렌지색, 녹색LED)
 CPU나 메모리 문제는 아님


2. RT 플랫폼(Pharlap, VxWorks) 최대 64개의 TCP/IP 소켓 연결만 가능함.
 소켓이 닫힌 이후 60초간 TCP/IP 스택이 대기하는 상황에서 문제 발생됨
 재접속 주기를 60초로 변경하면 어느정도 문제를 해결할 수 있음
 UDP socket-less 통신을 사용하는 것이 가장 나은 해결책

After a lot of pain and talks with NI Platinum support we found that the issue was caused by running out of tcp/ip sockets. The RT platforms, both Pharlap and VxWorks, have a limit of 64 simultaneous tcp/ip sockets. The problem is compounded by the tcp/ip stack holding on to any closed socket for 60 sec after closure.


In our application we had an RT PXI chassis with 14 simultaneous tcp/ip connections. We worked around the issue by limiting reconnect attempts only after a 60 sec delay. This solved the issue in the short term, but for the long term we had to move to UDP socket-less communication to our distributed cRIO targets.

3. 다른 경험적 해결책
 1) Timed Loop 내에 TCP/IP 루프를 두지 말 것
 2) Timed Loop 내에 File io를 두지 말 것
 3) Timed Loop 내에 공유 변수를 두지 말 것(FIFO, 글로벌 변수가 나은 방안)



<<가능한 해결책>
 1. TCP 루프의 재접속 주기를 60초로 변경
    -> 이미 120초로 사용 중임에도 연결끊김 발생
    -> 공유기나 스위치없이 사용시 발생빈도가 많아지고 주기가 짧아짐


 2. TCP 루프중 일부를 UDP로 변경
    -> 운전프로그램 연결을 UDP로 변경하는 안을 검토
    -> 공유기 아래에 있을 경우 포트 포워딩 등을 해주어야 하고, 방화벽 통과 못함
    -> UDP는 송 수신 모두 IP와 Port 에 의해 매번 새로 보내지므로 IP가 외부에서
      접근 불가하면 연결되지 않음