haskell의 ECG/EEG 센서 데이터를위한 RESTful 인터페이스

Question

휴대용 장치로 측정 한 바이오 센서 EEG/ECG 데이터를 표시하려는 프로젝트에서 작업 중입니다 (예 : Wifi 또는 Bluetooth를 통한 무선 데이터 전송이 가능한 마이크로 컨트롤러). 이 목적을 위해, 나는 많은 또는 일부 장치가 RESTful interfaces을 사용하는 것처럼 보이는 휴대용 장치/마이크로 컨트롤러와 인터페이스해야하지만 소켓도 제공해야합니다.

wifi가있는 마이크로 컨트롤러의 한 예는 WiFi 액세스 온보드를위한 cortex m3 및 CC3000 무선 컨트롤러를 기반으로하는 "spark.io"입니다. 전송되는 데이터는 초당 500-1000 개의 부동 소수점 값으로 REST 클라이언트에 가능한 한 지연없이 도착해야합니다. 아마 RESTFul 인터페이스를 기반으로 한 접근법을 테스트하고 싶다. (RESFul 인터페이스를 통해 데이터를 전송하는 것이 매우 보편적이며 좋은 라이브러리 지원을하는 것처럼 보인다.)

질문 : REST 인터페이스를 통해이 인터페이스와 인터페이스하는 (거의 실시간에 가까운) 구현 방법에 대한 최상의 접근 방법은 무엇입니까?

나는이 문제가 전에 해결되었다고 확신하지만, 이것을 설명하는 Google 학자 또는 기술/과학 블로그 게시물을 통해 신속하게 찾을 수 없습니다. 내가 찾은 유일한 링크는 "rest hooks"이지만, 이것이 좋은 접근 방법인지 확실하지 않습니다. SE에 대한 검색은 이것에 대한 과거의 질문을 밝히지 않았다.

사이드 노트 : 내 접근 방식은 먼저 RESKT 인터페이스의 디자인과 성능을 테스트하기 위해 인터페이스를 haskell에 구현하는 것입니다. 나중에 작동 방식을 Java/Android/spark.io/다른 마이크로 컨트롤러로 이식하거나 구현해야합니다.

(이 질문은 전적으로 아키텍처에 관한 것이지만 haskell 라이브러리 또는 기타 사항에 대해서는 전혀 언급하지 않습니다.) REST를 사용하는 것이 가장 멍청한 경우, 인수로 응답하는 것으로 받아 들일 것입니다. "spark.io"과 같은 일반적으로 마이크로 컨트롤러 웹 인터페이스와 API는 REST를 통해 구현되는 경우 일반적으로 어리석은 생각입니다. 그렇습니까? 그렇다면 "거의 실시간"의 정의는 REST 인터페이스는 좋지 않으므로 다른 센서를 사용하는 것이 좋습니다. 예 : 1 분당 하나의 센서 읽기 또는 1/10 초, 1/100 초, 1/1000 초, 1/1000 초)

Answer 1

자, 이걸 살펴 보겠습니다.

REST는 반드시 나쁜 아이디어는 아니지만 필요하지 않은 기능이 많이 있습니다. 예를 들어, 검색만을위한 것이 아니라 자원을 갱신, 삭제 및 작성하는 REST verb가 있습니다. 이러한 기능이 중요한 경우 (예 : 특정 제어 데이터를 EEG 컨트롤러로 보내야하는 경우) REST가 유용합니다. 데이터 스트림에 빠르게 액세스하려는 경우 원시 TCP를 대신 고려하십시오.

마찬가지로 REST는 요청을 처리 할 수 ​​있는지 여부, 압축 여부 등을 나타내는 "헤더"묶음과 함께 "요청"과 "응답"에 메시지를 패키지합니다. 이러한 기능은 훌륭한 기능 일 수 있지만 부 풀릴 수 있습니다. 헤더의 ~ 1kB가 작은 크기이므로 각 요청에 대해 충분한 데이터를 내보내려고합니다. 하지만 8 바이트 플로트 (double 초)가 주어지면 500-1000 데이터 포인트를 전송해야합니다.이 데이터 포인트는 약 1 초가 걸립니다. 그것은 우리의 운명인가? 항상 1 초의 대기 시간을 가졌습니까?

REST를 사용하면 Transfer-Encoding: chunked을 선언하여 이러한 확장을 피할 수 있습니다. 그래야 클라이언트가 개별 청크에서 작동 할 수있게됩니다. 이것이 내가해야 할 필요가있는 건축상의 결정입니다.

나는 가능한 한 빨리 Keep-Alive으로 일하게 될 것이며, 서버에서 사용할 라이브러리를 찾을 때 가장 중요한 기능이라고 할 수 있습니다. Keep-Alive은 HTTP에 대한 표준 확장으로서 각 HTTP 요청에 대해 TCP 스택을 찢어서 다시 작성하지 않습니다. 이 작업을 수행하지 않으면 요청을 보낼 때마다 프로토콜 협상이 필요합니다.

당신이해야 할 중요한 결정은 HTTP pipelining을 수행할지 여부와 관련됩니다. HTTP 파이프 라이닝과 긴 수명의 요청 (즉각적인 응답을 기대하지 않는 요청)을 결합하여 본질적으로 "데이터를 사용할 수있게되면 데이터를 보냅니다"(즉, 헤더를 먼저 보내고 서버가 좋은 시점에 서버를 밀어 내도록 할 수 있습니다 준비 완료). 이것은 청크 분할 전송에 대한 대안입니다.

이러한 작업을 수행 할 수 있다면 HTTP가 정기적으로 메가 바이트 (megabytes per second)를 보내는 데 사용되므로 유스 케이스는 REST가 수행 할 수있는 범위 내에서 잘 맞습니다. 하스켈의 REST/HTTP 라이브러리 측면에서 컨트롤러를 직접 프로그래밍해야하는 경우 큰 옵션은 wai, yesod, snap 및 rest입니다. HTTP 클라이언트가 필요한 경우에는 그 중 일부만 있습니다.