I have an application that uses a number of IP sockets including a server. Having got fed up with being nagged that TCPServer was depreciated every time I compiled my code, I decided to update using TCPSocket as mandated by the latest OS updates. TCPServer works well, is stable and reliable so I assumed TCPSocket would work the same way, but oh how wrong I was!
In typical MBED style, documentation on how to use TCPServer is utterly pitiful and examples completely non-existent, so I thought it may be useful for others to see the challenges I’ve found so they don’t need to waste the hours of their lives that I’ll certainly never see again, and also in the hope that MBED may be tempted to improve TCPServer by adding some basic error detection. Hopefully the team will also be shamed into improving the documentation, but I won’t hold my breath.
I’m using various IPsockets on the same thread and so ‘blocking’ is set to 0.
1) Accepting connections: On the old TCP Server if a connection was made to the server, it simply dropped any existing connection and accepted the new one. Very useful for killing errored connections and preventing multiple parallel connections. With TCPSocket Once a connection is accepted using:
TCPSocket *MyServerSocket;
MyServerSocket = sock.accept(&Error);
If another connection is made, the OS will crash!
2) Closing: Connections are closed using MyServerSocket ->close(); OK so far, but if you accidentally try and close a socket that’s already been closed then, the OS will crash!
3) Sending data: Sending data to an active socket using:
MyServerSocket ->send(out_buffer, sizeof(out_buffer));
Works great, but if the socket has disconnected for some reason, guess what happens? Yes, the OS will crash!
4) As there is nothing in the API to test if there is a connection or not, I tried using If (MyServerSocket) to see if I had a valid pointer to a socket. What I then found is that following MyServerSocket ->close(); MyServerSocket still points to something so If (MyServerSocket) returns true. I’ve managed to get round this by explicitly setting MyServerSocket to NULL when I close the socket.
So in summary, TCPSocket lacks the most basic error checking which was inherent in TCPServer which means it is very easy to crash MBED with any minor error. These challenges can be overcome, but it does seem retrograde step to have to write loads of extra code, when TCPServer worked perfectly in the first place, especially when it took me a week of testing to work out what was going on.
Johannes Stratmann.
2
replies
I have an application that uses a number of IP sockets including a server. Having got fed up with being nagged that TCPServer was depreciated every time I compiled my code, I decided to update using TCPSocket as mandated by the latest OS updates. TCPServer works well, is stable and reliable so I assumed TCPSocket would work the same way, but oh how wrong I was!
In typical MBED style, documentation on how to use TCPServer is utterly pitiful and examples completely non-existent, so I thought it may be useful for others to see the challenges I’ve found so they don’t need to waste the hours of their lives that I’ll certainly never see again, and also in the hope that MBED may be tempted to improve TCPServer by adding some basic error detection. Hopefully the team will also be shamed into improving the documentation, but I won’t hold my breath.
I’m using various IPsockets on the same thread and so ‘blocking’ is set to 0.
1) Accepting connections: On the old TCP Server if a connection was made to the server, it simply dropped any existing connection and accepted the new one. Very useful for killing errored connections and preventing multiple parallel connections. With TCPSocket Once a connection is accepted using:
TCPSocket *MyServerSocket; MyServerSocket = sock.accept(&Error);
If another connection is made, the OS will crash!
2) Closing: Connections are closed using MyServerSocket ->close(); OK so far, but if you accidentally try and close a socket that’s already been closed then, the OS will crash!
3) Sending data: Sending data to an active socket using:
MyServerSocket ->send(out_buffer, sizeof(out_buffer));
Works great, but if the socket has disconnected for some reason, guess what happens? Yes, the OS will crash!
4) As there is nothing in the API to test if there is a connection or not, I tried using If (MyServerSocket) to see if I had a valid pointer to a socket. What I then found is that following MyServerSocket ->close(); MyServerSocket still points to something so If (MyServerSocket) returns true. I’ve managed to get round this by explicitly setting MyServerSocket to NULL when I close the socket.
So in summary, TCPSocket lacks the most basic error checking which was inherent in TCPServer which means it is very easy to crash MBED with any minor error. These challenges can be overcome, but it does seem retrograde step to have to write loads of extra code, when TCPServer worked perfectly in the first place, especially when it took me a week of testing to work out what was going on.