Re: Eunet or EuLibnet or TCP socket library (or socket.e)
- Posted by ghaberek (admin) May 19, 2016
- 2530 views
The client-server communications will be quite sparse (and the user load light). At client initialisation the previous few months transactions (for that user) will be loaded into the client as a single read-only table. When a new transaction is created in the client it gets sent to the server which then confirms the event. That is really the core of the transmissions. So on the client side I think it would work as a synchronous socket call that times out. The dropped TCP connection could be managed by preceding each call with a check that the connection is still up.
I don't think you need to keep the TCP connections open between the clients and server. This is the process I imagine you'd take:
| # | Client | Server |
|---|---|---|
| 1 | Connect to server | |
| 2 | Accept connection from client | |
| 3 | Send request for new transaction ID | |
| 4 | Receive request for new transaction ID | |
| 5 | Send new transaction ID to client | |
| 6 | Receive new transaction ID | |
| 7 | Send transaction ID and data | |
| 8 | Receive transaction ID and data | |
| 9 | Send SUCCESS or FAILED status | |
| 10 | Close client socket | |
| 11 | Receive status from server | |
| 12 | Close local socket |
This is how a lot of simple TCP protocols, like HTTP, work: the connection only lives for the duration of the request. More advanced protocols (especially databases) utilize connection pooling, which allows the programmer to design the application as if the connection were always open, but underneath, the connection can idle out, time out, error out, create multiple channels, etc. without the programmer ever knowing. But we don't really have that luxury with core sockets.
Can select be used to check connectivity? I presume so since socket.e refers to ERR_NOTCONN indicating that I can test for that condition.
That's exactly what select() is for: to poll the state of one or more sockets and act accordingly. However, as stated, I would not recommend relying on the TCP connection to remain open. It's a lot easier if your connections have the same lifetime as your transactions.
I would prefer to not use tasks, if at all possible. Would some form of polling work instead?
You certainly don't need to use tasks. I use tasks to provide a stronger separation of concerns in my networking model. That is, there the primary task is listening for new connections and additional tasks (or one task processing a queue) is handling the clients' data in chunks at a time. But since your data sizes are so small, I doubt you'll need to break things down into chunks.
-Greg
