I am getting strange input in my windows message callback.
Besides all the normal messages, like WM_SIZE, which work fine, there are some messages that do not appear in any table, like this one. And they are not defined as error codes, either.
The messages are: (decimal / hex)
356 / 0164 (wParam: 0, lParam: 5760884)
49291 / c08b (wParam: 4294967292 or 0, lParam: 0)
49348 / c0c4 (wParam: 0, lParam: 0)
Does anybody know what they mean, or why I am gettting them?
Per the Win32 documentation:
The following are the ranges of message numbers.
Range Meaning
0 through WM_USER–1 Messages reserved for use by the system.
WM_USER through 0x7FFF Integer messages for use by private window classes.
WM_APP (0x8000) through 0xBFFF Messages available for use by applications.
0xC000 through 0xFFFF String messages for use by applications.
Greater than 0xFFFF Reserved by the system.
Message numbers in the first range (0 through WM_USER –1) are defined by the system. Values in this range that are not explicitly defined are reserved by the system.
Message numbers in the second range (WM_USER through 0x7FFF) can be defined and used by an application to send messages within a private window class. These values cannot be used to define messages that are meaningful throughout an application because some predefined window classes already define values in this range. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use these values. Messages in this range should not be sent to other applications unless the applications have been designed to exchange messages and to attach the same meaning to the message numbers.
Message numbers in the third range (0x8000 through 0xBFFF) are available for applications to use as private messages. Messages in this range do not conflict with system messages.
Message numbers in the fourth range (0xC000 through 0xFFFF) are defined at run time when an application calls the RegisterWindowMessage function to retrieve a message number for a string. All applications that register the same string can use the associated message number for exchanging messages. The actual message number, however, is not a constant and cannot be assumed to be the same between different sessions.
Message numbers in the fifth range (greater than 0xFFFF) are reserved by the system.
Where WM_USER is 0x0400.
So,
356 (0x164) is a system reserved message. Specifically, it is CB_GETCOMBOBOXINFO.
49291 (0xC08B) and 49348 (0xC0C4) are string messages that have been registered with RegisterWindowMessage() at runtime. You may be able to use GetClipboardFormatName() to retrieve the original string value used for the registration, as RegisterWindowMessage() and RegisterClipboardFormat() usually share a common atom table.
Related
The message format is
!AIVDM,2,1,,B,177KQJ5000G?tO`K>RA1wUbN0TKH,0*5C
The second field (in this case, 2), designates the number of parts in the AIS message and the third field (in this case, 1) indicates the part or fragment sequence.
If the messages do NOT arrive in sequence, is there a fail safe method of linking the message fragments? [I understand that several fragments can arrive in random order.]
Message parts must follow an order.If they are not sequential you should not take the message into account.IEC 61162 document which is a standard defines the structures of NMEA sentences including AIS messages,says that the multipart messages have to be in order.If you are facing messages in random order it is a hardware failure as manufacturer have to obey the rules defined in IEC 61162 Standard.
The AIS payloads are encapsulated within the NMEA message format -- NMEA sees them only as a black box -- so you should not expect a NMEA parser to be sensitive to the encoded AIS content.
If you were desperate, you could try to match the multipart messages by the expected lengths of each AIS payload message type, but you'd run into the following problems:
Some message types (e.g. type 8: Binary Broadcast Message) have a variable length
There are conventions for aligning messages on byte boundaries that are not always followed, so even fixed-length messages can be received with differing lengths (e.g. type 15).
The best you can do in practice is assume that multipart messages may only arrive interleaved if the two messages have different NMEA message types (e.g. one message is AIVDM, and the other is SAVDM). This is the approach taken in the NMEA parsing library I wrote, under each_complete_message.
You could go further and use the total number of message parts as a way to differentiate messages, but in practice 3-part messages seem to be exceedingly rare.
TL;DR
No, there is no fail safe method of linking fragments.
Maybe you can check why the third field is empty and whether it can be activated.
ShineMicro uses it in the following way:
!AIVDM,X1,X2,X3,A,S--S,X4*CRC
where
X1 - total number of sentences (parts) needed to transmit 1 AIS message
X2 - sentence number (1 to 9)
X3 - sequential message identifier (0-9), sequentially assigned and is incremented for each new multy-sentences message
If you are using Python, you can use the libais library: https://github.com/schwehr/libais/. The NmeaQueue works a FIFO queue and does the job for you.
Just put all the messages (whatever the order) in the queue, and call the pop method if the length of the queue is positive. It handles single & multipart messages.
import ais
q = ais.nmea_queue.NmeaQueue()
for msg in msg_generator: # can be a list for instance
q.put(msg)
if q.qsize():
d = q.get().get('decoded', None)
print
I have a server sending a multi-dimensional character array
char buff1[][3] = { {0xff,0xfd,0x18} , {0xff,0xfd,0x1e} , {0xff,0xfd,21} }
In this case the buff1 carries 3 messages (each having 3 characters). There could be multiple instances of buffers on server side with messages of variable length (Note : each message will always have 3 characters). viz
char buff2[][3] = { {0xff,0xfd,0x20},{0xff,0xfd,0x27}}
How should I store the size of these buffers on client side while compiling the code.
The server should send information about the length (and any other structure) of the message with the message as part of the message.
An easy way to do that is to send the number of bytes in the message first, then the bytes in the message. Often you also want to send the version of the protocol (so you can detect mismatches) and maybe even a message id header (so you can send more than one kind of message).
If blazing fast performance isn't the goal (and you are talking over a network interface, which tends to be slower than computers: parsing may be cheap enough that you don't care), using a higher level protocol or format is sometimes a good idea (json, xml, whatever). This also helps with debugging problems, because instead of debugging your custom protocol, you get to debug the higher level format.
Alternatively, you can send some sign that the sequence has terminated. If there is a value that is never a valid sequence element (such as 0,0,0), you could send that to say "no more data". Or you could send each element with a header saying if it is the last element, or the header could say that this element doesn't exist and the last element was the previous one.
I have an application (native C++, Windows), that cannot be run simultaneously on one machine. The behavior that I want to implement is this: on the attempt to run second instance of the application the first one stops running.
To do so I want to use WinApi function BroadcastSystemMessage() something like an example below.
When the application start it sends:
BroadcastSystemMessage(BSF_POSTMESSAGE, &dwRecepients, 0x666, 0, 0);
But, when I run my application in debug mode it doesn't hit
case 0x666:
int iClose = 0 + 1;
break;
when I start another instance. The other messages are nandled correctly (WM_KEYDOWN, WM_ACTIVATE and others).
What I'm I doing wrong?
In order to broadcast a custom message you need to create an id for it with the RegisterWindowMessage function, for example:
UINT msg666 = RegisterWindowMessage(L"custom_devil_message");
and use it both in the sending and receiving code:
// sending code
BroadcastSystemMessage(BSF_POSTMESSAGE, &dwRecepients, msg666, 0, 0);
// receiving code
case msg666:
int iClose = 0 + 1;
break;
Remember that messages do not work for console applications.
The solution began to work after I changed the type of the message to WM_APPCOMMAND + 10. Anyway, it didn't help, because BroadcastSystemMessage() doesn't broadcast messages to tabs in a browser, which is my case. Also, I couldn't find the range of message types that are allowed to be sent with BroadcastSystemMessage().
Given a Windows socket, I want to determine which values it is using for the TCP keepalive idle time and the TCP keepalive interval time (roughly equivalent to the TCP_KEEPIDLE and TCP_KEEPINTVL settings on Berkeley sockets).
I see that you can set these values using a WSAIoctl call (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx ). However, there does not appear to be any API for reading their current values. I tried calling WSAIoctl with a populated output parameter but NULL input parameter, like this:
DWORD bytes_returned;
struct tcp_keepalive keepalive_opts;
int rv = WSAIoctl(socket, SIO_KEEPALIVE_VALS, NULL, 0, &keepalive_opts, sizeof(keepalive_opts), &bytes_returned, NULL, NULL);
But this returns me a WSAEFAULT ("The system detected an invalid pointer address in attempting to use a pointer argument in a call.").
I could call WSAIoctl with both an input and an output parameter, but I don't want to set the values, I just want to read them. And as far as I can tell, providing any non-NULL input parameter would cause the parameters to be set to whatever values happen to be in that memory space (defined by the struct tcp_keepalive; again see http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx ).
The above also highlights another problem with not knowing what the current values are: I can't set just one of the keepalive idle time or the keepalive interval time - I must blow away both (unknown) values at the same time since they're both members of the struct I'm required to provide.
I know that I could assume things about what values are set based on Windows documentation, but I'd rather not assume. I see that http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA defines KeepAliveInterval and KeepAliveTime default values. However, the Parameters folder in my Windows 7 registry does not contain either of those keys, so I really have to rely on the documentation being 100% correct here (to know the default values a socket will receive), which is much worse than programmatically retrieving them (even retrieving them from the registry might be ok, but the above experience shows I can't).
Is there any way to get the current TCP keepalive idle time and the TCP keepalive interval time values for a Windows socket?
Unlike TCP_KEEPIDLE and TCP_KEEPINTVL, which can be used with getsockopt(), there is no way to read the current SIO_KEEPALIVE_VALS values for a socket, only to set them.
I made a simple protocol for my game:
b = bool
i = int
sINT: = string whose length is INT followed by a : then the string
m = int message id.
Example:
m133s11:Hello Worldi-57989b0b1b0
This would be:
Message ID 133
String 'Hello World' length 11
int -57989
bool false
bool true
bool false
I did not know however that TCP could potentially only send PART of a message. I'm not sure exactly how I could modify this such that I can do the following:
on receive data from client:
use client's chunk parser
process data
if has partial message then try to find matching END
if no partial messages then try to read a whole message
for each complete message in queue, dispatch it
I could do this by adding B at the beginning of a message and E at the end, then parsing through for the first char to be B and last to be E.
The only problem is what if
I receive something silly in the middle that does not follow the protocol. Or, what if I was supposed to just receive something that is not a message and is just a string. So if I was somehow intended to receive the string HelloB, then I would parse this as hello and the beginning of a message, but I would never receive that message because it is not a message.
How could I modify my protocol to solve these potential issues? As much as I anticipate only ever receiving correctly formed messages, it would be a nightmare if one was poorly encoded and set everything out of whack.
Thanks
I decided to add the length at the beginning and keep track of if I'm working on a message or not:
so:
p32m133s11:Hello Worldi-57989b0b1b0
I then have 3 states, reading to find 'p', reading to find the length after 'p' or reading bytes until length bytes have been read.
What do you think?
It seems to work great.
What you are doing is pretty old-school, magnetic tape stuff. Nice.
The issue you might have is that if a part of the message is received, you cannot tell if you are partway through a token.
E.g. if you receive:
m12
Is this Message 12, or is it the first part of message 122?
If you receive:
i-12
Is this an integer -12 or is it the first part of an integer -124354?
So I think you need to change it so that the message numbers are fixed width (e.g. four digits), the string length is fixed (e.g. 6 digits) and the integer width is fixed at 10 digits.
So your example would be:
m_133s____11:Hello Worldi____-57989b0b1b0
That way if you get the first part of a message you can store it and wait for the remainder to be received before you process it.
You might also consider using control characters to separate message parts. There are ascii control codes often used for this purpose, RS, FS, GS and US. So a message could be
[RS]FieldName[US]FieldValue[RS]fieldName[US]FieldValue[GS].
You know when you have a complete message because the [GS] marks the end. You can then divide it up into fields using the [RS] as a separator, and split each into name/value using the [US].
See http://en.wikipedia.org/wiki/C0_and_C1_control_codes for a brief bit of information.