02-16-2025, 02:13 AM
The underlying problem is that `GET` does not wait for the data to arrive, if the client has not yet received enough data for your variable then it simply leaves the variable as-is and sets the EOF flag. Because of that, your `PUT` followed by an immediate `GET` of a LONG is very likely to fail because the other program won't have sent its response in time. You can check for this failure by checking `EOF(X)` after the `GET`, if it's set then that indicates the `GET` was unsuccessful.
The simple solution is to just loop until `EOF()` is false, indicating you received the data. You should additionally check `_CONNECTED(X)` in the loop to determine whether the client was disconnected (you don't want to keep looping on `GET` if no data will ever come).
On the `Server.bas` side of things it gets a bit trickier. The `GET`s` in there are unlikely to fail because the messages are currently very short, but you should still be checking `EOF()` and looping to ensure they're successfully received. That approach will be ok at a certain scale but it's not ideal because during the loop the server can't do anything else and you never really know if the client will send the rest of the message. There's a large variety of solutions to this issue, but I'd consider prefixing the messages with a length, that way you can have the main code wait until an entire message is received before you start processing it, then the rest of the code can simply handle the message without having to deal with the connection.
The simple solution is to just loop until `EOF()` is false, indicating you received the data. You should additionally check `_CONNECTED(X)` in the loop to determine whether the client was disconnected (you don't want to keep looping on `GET` if no data will ever come).
On the `Server.bas` side of things it gets a bit trickier. The `GET`s` in there are unlikely to fail because the messages are currently very short, but you should still be checking `EOF()` and looping to ensure they're successfully received. That approach will be ok at a certain scale but it's not ideal because during the loop the server can't do anything else and you never really know if the client will send the rest of the message. There's a large variety of solutions to this issue, but I'd consider prefixing the messages with a length, that way you can have the main code wait until an entire message is received before you start processing it, then the rest of the code can simply handle the message without having to deal with the connection.