|
I have sent the packet through tcp socket. when i was analyzing the packet through wireshark i was getting the packet in the server side like below :
2E 60 01 23 06 08 20 20 01 c0 00 .5 .#.... .....
92 12 01 23 48 30 30 30 30 30 30 ...#H000009
39 53 31 30 30 30 30 30 30 30 30
30 30 30 30 35 9S10000000000005
while my actual packet is
00 2E 60 01 23 06 00 08 00 20 20 01 00 00 c0 00 .5 .#.... .....
00 92 00 00 00 00 12 01 23 48 30 30 30 30 30 30 ........#H000009
39 53 31 30 30 30 30 30 30 30 30 30 30 30 30 35 9S10000000000005
Why all 00 bytes are not getting sent..Can anybody tell me.
Please Help !!!!!
|
|
|
|
|
Once again, read the ISO standard carefully, it is explained nicely there.
And you might want to learn about sockets, or post the problem with the socket separately.
|
|
|
|
|
Message Closed
modified 25-Apr-13 3:33am.
|
|
|
|
|
Pleas edit this entry and remove the blockquote surrounding the code and replace with <pre> tags, so your code is readable.
Use the best guess
|
|
|
|
|
|
1. I guess you did not understand what "please edit the above entry" means.
2. Check what?
Use the best guess
|
|
|
|
|
Hello Sir,
I really did not understand what "please edit the above entry" means. Can you pls tell me..
Do I need to edit something in the code or is this not the write way to post the code?
Thanks
|
|
|
|
|
He kindly asked you to edit your existing post (there is a button to do so) and format the source code so that it is readable. To do so, select the code section and click the 'code' button above the editor window or place a <pre> tag at the begin of the code and a </pre> at the end (when clicking the 'code' button this is done automatically). In all cases, check the preview window below the editor window.
In the editor window it should look like this:
<pre lang="c++">
// A comment
#include <stdio.h>
int main()
{
return 0;
}</pre>
Then the preview (and the final post) will look like this:
#include <stdio.h>
int main()
{
return 0;
}
|
|
|
|
|
00 2E 60 01 23 06 00 08 00 20 20 01 00 00 c0 00
00 92 00 00 00 00 12 01 23 48 30 30 30 30 30 30
39 53 31 30 30 30 30 30 30 30 30 30 30 30 30 35
#include <WS2tcpip.h>
#include <stdio.h>
#include <stdlib.h>
#include <WinSock.h>
#include <wchar.h>
#include <string.h>
char cHexDigit_to_Nibble1(unsigned char c)
{
if(!isxdigit(c))
return (0);
if(isdigit(c))
return (c - '0');
c = toupper(c);
return (c - 55);
}
void vAscii2BCD(unsigned char *pucSrc, unsigned char *pucDst, int inSize)
{
for (; inSize > 0; inSize -= 2, pucDst++)
{
if(!memcmp(pucSrc, "3D", 2))
{
pucSrc += 2;
*pucDst = '=';
}
else
{
*pucDst = cHexDigit_to_Nibble1(*pucSrc++) << 4;
*pucDst |= cHexDigit_to_Nibble1(*pucSrc++);
}
}
printf("data is %s\n\n",pucDst);
}
int main()
{
int sock_desc, status;
struct sockaddr_in client;
struct addrinfo hints;
WSADATA Data;
int bytesSent;
int bytesRecv = SOCKET_ERROR;
unsigned char *pucSrc = (unsigned char*) malloc (100) ;
unsigned char *pucDst = (unsigned char*) malloc (256) ;
memset(pucSrc,0,256);
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"00" ,pucDst, 1) ;strcpy((char*)pucSrc,(char*)pucDst) ;
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"2E" ,pucDst, 1) ;strcat((char*)pucSrc,(char*)pucDst) ;
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"6001230600" ,pucDst, 5) ;strcat((char*)pucSrc,(char*)pucDst) ;
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"0800" ,pucDst, 2) ;strcat((char*)pucSrc,(char*)pucDst);
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"2020010000" ,pucDst, 5) ;
strcat((char*)pucSrc,(char*)pucDst);
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"C00000" ,pucDst, 3) ;
strcat((char*)pucSrc,(char*)pucDst);
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"920000" ,pucDst, 3) ;
strcat((char*)pucSrc,(char*)pucDst);
printf("size of pucSrc = %d\n", strlen((char*)pucSrc));
vAscii2BCD((unsigned char*) "0000" ,pucDst, 2) ;
strcat((char*)pucSrc,(char*)pucDst) ;
printf("size of pucSrc = %d\n", strlen((char*)pucSrc));
memset(pucDst,0,256);
vAscii2BCD((unsigned char*) "12" ,pucDst, 1) ;strcat((char*)pucSrc,(char*)pucDst) ;
memset(pucDst,0,256);
vAscii2BCD((unsigned char*)"0123" ,pucDst, 3) ;strcat((char*)pucSrc,(char*)pucDst) ;
strcat((char*)pucSrc,"H0000009S10000000000005");
printf("size of pucSrc = %d\n", strlen((char*)pucSrc));
status = WSAStartup(MAKEWORD(2, 2), &Data);
if(status != 0)
{
printf("ERROR: WSAStartup unsuccessful");
return 0;
}
else
{
printf("WSAStartup Successfull\n");
}
sock_desc = socket(AF_INET,SOCK_STREAM,0);
if ( sock_desc == INVALID_SOCKET ) {
printf( "Error at socket(): %ld\n", WSAGetLastError() );
WSACleanup();
return;
}
client.sin_family = AF_INET;
client.sin_addr.s_addr = inet_addr( "41.208.68.76" );
client.sin_port = htons( 4444 );
if(connect(sock_desc,(struct sockaddr*)&client,sizeof(client)) == SOCKET_ERROR) {
printf( "Failed to connect.\n" );
WSACleanup();
return;
} else{
printf("connect successfull\n");
}
bytesSent = send( sock_desc, pucSrc, strlen(pucSrc), 0 );
printf( "Bytes Sent: %ld\n", bytesSent );
while( bytesRecv == SOCKET_ERROR ) {
bytesRecv = recv( sock_desc, recvbuf, 256, 0 );
if ( bytesRecv == 0 || bytesRecv == WSAECONNRESET ) {
printf( "Connection Closed.\n");
break;
}
printf( "Bytes Recv: %ld\n", bytesRecv );
if (bytesRecv < 0)
return;
printf( "Bytes Recv: %ld\n", bytesRecv );
}
return 0;
}
when I was analyzing the packet through wireshark I was getting the packet in the server side like below :
2E 60 01 23 06 08 20 20 01 c0 00
92 12 01 23 48 30 30 30 30 30 30
39 53 31 30 30 30 30 30 30 30 30
30 30 30 30 35
Why all 00 bytes are not getting sent.
|
|
|
|
|
You are using string functions (strcpy() etc.) to copy your data (which are not strings) from one buffer to another, so each copy will stop as soon as it hits a zero character. Use memcpy() and ensure you copy the exact number of bytes that you wish to transfer.
Use the best guess
|
|
|
|
|
Hi All,
I have made an MCI player which plays ".wav" file well using MCISendString command.
Now I want my application to get number of headsets (audio output)devices attached. I want to play my wave file simultaneously in all the audio output devices.
Please help!
Thanks in advance 
|
|
|
|
|
|
Hi i have developed an tool which writes data into the MS-Access file (Eg: empdata.mdb which exist in remote pc).
- Certainly this exe will run in many machine across network( Approxmatively 30 machines)
When i run the exe in diffrent machines (windows 7) it giving
the following error.
"It is already opened exclusively by another user , or u need permission to view its data."
Could anyone help in resolving the issues.
Thanks & Regards
Mani
|
|
|
|
|
The error message indicates that the database has been opened by another application with exclusive access or the user hasn't sufficient privileges to access the database file.
When using the CDaoDatabase class, pass FALSE as second parameter to the Open() function.
When using Access, it must be configured to open files in shared mode (this is the default).
The database file must be readable and writable for the users.
See also Ways to share an Access database[^].
|
|
|
|
|
Hi,
Is it 'thread safe' to use API'slike
::SetWinowText(...) and
::ShowWindow(hWnd,nCmdShow) across threads, or should I use e.g.
::SendMessage(hWnd,WM_SHOWWINDOW,fShow,bShow) I want to Hide and Show and set aspects of a Progress Dialog box during the run of the worker thread.
Regards,
Bram van Kampen
|
|
|
|
|
It is always recommended to use SendMessage to the UI thread so that the UI thread controls/manipulates its UI elements.
In some cases it may not be necessary like, for example, the documentation for SetWindowText says that a WM_SETTEXT message is send by the API.
|
|
|
|
|
«_Superman_» wrote: It is always recommended to use SendMessage to the UI thread...
But what about deadlock?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
SendMessage is the right way to avoid deadlocks.
This way all requests from any thread is always queued in the UI thread message loop.
So keeping all locks local to the message handlers will help in avoiding deadlocks.
|
|
|
|
|
«_Superman_» wrote: SendMessage is the right way to avoid deadlocks.
This article would tend to disagree.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
hi,
i have to implement one method to get all domain names from adsi forest in c++ anyone tell that how can do that in c++.
thanks
|
|
|
|
|
I think my past sins and assumptions are coming home to haunt me. I have a fairly large/complex application that began its past life in another product. Consider it a dialog application with a lot of dialogs. The dialogs can become 3 or more deep. On rare and random occasions, the application will crash with a stack overflow exception - only when leaving a dialog. The exception happens somewhere after EndDialog processes.
Yes, I have checked stack usage - I'm well under the specified amount. The problem is very rare. My debug efforts have led me to the path of suspecting some sort of race condition in message processing or some other undetected data corruption.
The application itself uses your standard windows messages. However, I have a number of worker threads that post messages into the application message queues. My approach is what I need a basic sanity check on
In the InitInstance, I create a worker thread using ::CreateThread() - system timer, whose sole responsibility is to notify active dialogs that a time event has occurred. This thread:
- acquires a pointer to CWnd via AfxGetApp().
- posts the message to the window using PosteMessage()
- there is no stack allocated data passed of any kind whatsoever in these messages.
Based on what I have read about this approach, it's legal and the only appropriate way for a worker thread to send data to the GUI thread. Opinions?
My next question has to do with what I consider to be a possible race condition. Given that my worker thread is firing off messages irrespective of what is going on elsewhere in the application, is it possible for the worker thread to send a message to a window AND have the user press the "Exit" button before the message arrives? If so, I would expect the dialog to be in some sort of tear down state such that some of it's processing is indeterminate. Is my concern reasonable?
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Imagine the gui thread as a special thread that has a job queue (because it has one). The main loop of the application (in the gui thread) is spinning and gets/processes messages that it retrievees with PeekMessage() or GetMessage() from its per-thread message queue. Putting a message to this message queue with PostMessage() for later processing is OK. Putting a message to the queue with SendMessage() is also OK. The difference between the two is that SendMessage() waits till the end of message processing so you can safely pass even pointers that point to your stack, and you can process the return value immediately. To tell the exact reason of your problem you need to give more info:
Which CWnd? Main wnd? Dialog wnd? What is the scope/lifetime of the CWnd? What is the scope/lifetime of the thread? Which Exit button? The one that terminates the whole application or just one of your dialog boxes?
There are several other things you should consider: MFC itself is not thread safe. If you use for example CWnd retriever methods than you are accessing a window map that is sometimes modified by the gui thread. Maybe your only problem is that you should get a HWND on the gui thread and pass that as a message target to the worker thread when you create it. Another possible problem is that on the main thread you should ask the worker thread to terminate and wait for it to terminate at some point. For example when the main window is destructed.
|
|
|
|
|
All good points. I know about SendMessage / PostMessage, and I've read many articles documenting why you need to be very careful sending messages in mfc. I'll see if I can come up with a description that isn't worse than I've already written . Note that this basic architecture was inherited, so I make no claim as to its validity. It's an approach, and it has worked. However in writing this out, I think I've discovered one issue...
- The worker thread is a child of the CWinApp application. It exists for the lifetime of the application.
- Window structure: CWinApp -> CFrameWnd -> Main Dialog -> many more dialogs. The frame object serves as the persistent object of the application. There are times when the main dialog may go away, so the frame object maintains application context. Normally, the CFrameWnd will instantiate the Main Dialog.
The frame object is created like so, its instance is saved away for the application:
CFrameWnd* pFrameWnd = new CFrameWnd;
m_pMainWnd = pFrameWnd;
- Every dialog created registers with the frame object its instance (using this). This is done so that when a general message is posted to the frame, the frame then echoes it out to all existing dialogs.
- The timer thread posts the timer message indirectly by invoking a public helper method from the frame object: pFrame->BroadcastTimerEvent(); The fact that a worker thread is using an object from the UI side of application CANNOT be a good thing. Comments?
In this BroadcastTimerEvent method, we finally post a message into the message queue:
<pre>Wnd * pWindow;
pWindow = AfxGetApp()->m_pMainWnd;
if (NULL != pWindow) pWindow->PostMessage(WM_DATA_TIMER);
This effectively queues the message to arrive and be handled by the frame's OnDataTimer handler. Note from above that I mentioned I keep track of all active dialogs. This is done to ease pushing out the timer events to all existing dialogs:
<pre>LRESULT CFrameWnd::OnPanelDataTimer(WPARAM wParam, LPARAM lParam)
{
if (NULL != m_pClientWnd) {
if (NULL != m_pClientWnd->m_hWnd)
{
for(SHORT j = m_pDialogsInUse.GetSize() - 1; j >= 0; j--)
if (m_pDialogsInUse[j]->m_hWnd != NULL)
m_pDialogsInUse[j]->PostMessage(WM_DATA_TIMER);
}
}
return 0;
}
So, I finally come back to my race condition issue - the timer thread fires and starts to push messages out as described. The user happens to press the dialog exit button. Standard button, invokes EndDialog() and terminates. Windows now goes about tearing down that dialog. This dialog has been created on the stack, so it's still out there for a brief period of time. This is where I think there might be a problem...
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
You described a lot of things but the 2 main things you have to make sure are still the same:
1. From the worker thread you shouldn't use any data structures and mfc calls that are not thread safe. You can provide this by posting messages directly to a HWND, but calling object methods is also OK if you can guarantee thread safety.
2. Make sure that the thread is terminated before the objects it interacts with are destroyed. I recommended sending an exit request signal to the thread and the waiting for it to terminate from the destroy of the main window.
From your comments none of these can be checked.
|
|
|
|
|
Item 2 - got it. But remember, it's not the application that's terminating, it's a single dialog.
Item 1 - you see how I am invoking PostMessage, from the CWnd object. This object has an m_hWnd variable, but how would I post a message using this? Based on what you have said, I'm not thread safe.
I'm tired, so might be a brain fart question....
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
