Hi,
I have a Websocket connection to a Chrome browser.
When Netburner pushes data, all god, no issues whatsoever.
However, when I try to push data from the browser to Netburner, I get an issue with messages >125 bytes (first sending is ok, the rest is garbage until I re-establish the Websocket connection. If the messages are below 126 bytes, all is good).
Output from the below is:
(if I am sending 125 bytes)
Websocket_fd read_fds received len=125 first=30
Websocket_fd read_fds received len=125 first=30
Websocket_fd read_fds received len=125 first=30
Websocket_fd read_fds received len=125 first=30
(if I am sending 126 bytes)
Websocket_fd read_fds received len=126 first=30
Websocket_fd read_fds received len=134 first=B8
Websocket_fd read_fds received len=134 first=30
Websocket_fd read_fds received len=134 first=B8
void TaskWebInput(void *pd)
{
while(1)
{
fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(Websocket_fd, &read_fds);
if (select(FD_SETSIZE, &read_fds, (fd_set *)0, (fd_set *)0, TICKS_PER_SECOND * 5))
{
if (FD_ISSET(Websocket_fd, &read_fds))
{
char buffer[256];
memset(buffer, 0, sizeof(buffer));
int ret = read(Websocket_fd, buffer, sizeof(buffer));
iprintf("Websocket_fd read_fds received len=%i first=%02X\r\n", ret, buffer[0]);
}
}
}
}
On client side (triggered from a button that I push several times):
[125 bytes code]
var s="";
for(var i=0;i<12;i++)
s=s+"0123456789";
s=s+"01234";
ws.send(s);
console.log(s); // all the messages look perfectly fine in the log
[126 bytes code]
var s="";
for(var i=0;i<12;i++)
s=s+"0123456789";
s=s+"012345"; // just one more to get 126 bytes
ws.send(s);
console.log(s); // all the messages look perfectly fine in the log
Any ideas?
Websocket browser-to-Netburner length issue
Re: Websocket browser-to-Netburner length issue
MODM7, version 3.2.0
Re: Websocket browser-to-Netburner length issue
Remove the HTONS from line ~173 of 'nbrtos/source/websocket_server.cpp'
Additionally, remove the HTONL from line ~202 of the same file
Somewhere along the line the websocket frame structures were updated to use the BigEndian autoconversion types and the explicit byte swap calls were left in place here. As a result, the first frame of size > 125 is misread as being ~32KB long instead of whatever length it actually is. This means that the next frame received will be interpreted as more payload data from the first.
Code: Select all
m_remLen = m_remainingLen = HTONS(frame->length);
Code: Select all
m_remLen = m_remainingLen = HTONL(frame->lengthLo);
Dan Ciliske
Project Engineer
Netburner, Inc
Project Engineer
Netburner, Inc
Re: Websocket browser-to-Netburner length issue
Thanks Dan, fixed the issue
-
- Posts: 624
- Joined: Mon May 12, 2008 10:55 am
Re: Websocket browser-to-Netburner length issue
I'm using v2.9.5, and it has the same lines of code that zealott was told to modify. Should I make the same modification?
The reason I ask is that we are having issues with websockets as well, but only when using an SSL connection. If the browser sends 3-messages to the module, the module won't see msg 1 until msg 3 received. It won't see msg 2 until msg 4 is received. These are short messages, less than the 125 byte that zealott was sending.
The reason I ask is that we are having issues with websockets as well, but only when using an SSL connection. If the browser sends 3-messages to the module, the module won't see msg 1 until msg 3 received. It won't see msg 2 until msg 4 is received. These are short messages, less than the 125 byte that zealott was sending.