|
I need to write a winsock application that captures localhost process packet information. That includes Server host name, ports, all the requests and responses.
How to do that in MFC/SDK. Do i need to write a asychronous raw socket application that monitors the localhost or write a dll injector that monitor all the host process api calls.
Which is better?
|
|
|
|
|
Hello Programmers ...
I am trying to develop a software which enables the PC to comunicate with a bluetooth device ...
I want an SDK or anything to help me with this ...
The function i want to use are:
search -> searchs for bluetooth devices and returns the avalible ID's.
Find -> bool function that searches for a certain ID.
send -> sends a file to a certain ID.
and thank you very much for your time ...
when i was right no one could remember me ...
but when i was wrong no one could forget me ...
(I saw it on an icecream truck when I was kid)
|
|
|
|
|
MSDN have many functions provided to manage the Bluetooth protocol...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
do you have a link that can give me more information ??
I searched for "MSDN bluetooth" in google .
I got many ruls bu I don't know which I should use ...
-*-*-*-*-*-*-*-*-*-*-*-*-*-*
when i was right no one could remember me ...
but when i was wrong no one could forget me ...
(I saw it on an icecream truck when I was kid)
|
|
|
|
|
you found this[^] ?
what are you lookin for exactly ?
for me, everything you need is dispatched into the 3 sections explained there...
...but you have to install the SDK...!
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
I was hoping that I could get some tips on how I could structure a (piece of a) program that does the following:
* Listens for incoming UDP broadcasts (using recvfrom) on port 1337.
* Send periodic UDP broadcasts (every 5-60 seconds or so).
* Maintains a table of IP addresses of recently received broadcasts and periodically checking if no broadcasts have been received from a particular address in, say, 5 minutes.
Address | Last received
--------------------------------
192.168.0.1 | 12:43:11
192.168.0.101 | 09:11:27
193.129.163.12 | 23:23:07
One way of doing it would be using three separate threads (pseudocode):
thread T1 {
loop {
Listen for broadcast
Add to/update table
}
}
thread T2 {
loop {
Send broadcast
Sleep for 30 seconds
}
}
thread T3 {
loop {
Check timestamps in table
Take appropriate action if a timestamp is too old
Sleep for 2 minutes
}
}
This will work but involves more threads than I feel is needed (unnecesary risk of sync problems etc.) since none of the actions really need to be interleaved. Any suggestions?
Johan Tibell
|
|
|
|
|
I agree, that in the described level of functionality are three threads an unnecessary overhead.
Just firing from the head - you can join at least threads T2 and T3 to one.
then it would be something like:
threadT23
{
loopCounter = 0;
loop
{
Sleep for 30 seconds
Send broadcast
if( loopCounter == 4 )
{
do the T3 work
}
loopCounter++;
if( loopCounter > 4 ) loopCounter = 0;
}
}
similary you can join the T1 with T23, only thing you need is some sort of nonblocking listen.
This is just an idea from the scratch, so not necessarily the best one, but at least something... 
|
|
|
|
|
This is off the top of my head too.. I haven't done much with UDD but I have had alot of experience with TCP.. anyway you could.... use 'network events' to trigger the FD_READ and FD_ACCEPT events catch UDD connections accept them and then read any data sent.. (again i know this works great for TCP, but im not sure how events work if they even work at all for UDD you'll have to look into that)..
Then use 2 timers in your program one to send your broadcasts every 30 seconds and another set to 2 minutes to check your timestamps and take appropriate action if needed..
The only reason you would want to do any of this in seperate threads is if any of the functions bog down your GUI..
Hope this helps..
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Actually I was hoping that I could avoid using a HWND which is needed for the timers (that I know of). I would prefer if my network module could be seperated from the UI part.
|
|
|
|
|
HWND required for timers?
What is your target platform? If you are targeting Windows 98 or later, then look into CreateWaitableTimer. I can't help but be amused at the number of solutions that go out of their way to make a window of some sort just because they think SetTimer is the only way to get a timeout message in an application 
|
|
|
|
|
The ideal situation would be if could (without relying on windows) do the following:
thread T1 {
loop {
wait for (received datagram OR
update table event OR
send broadcast event) {
}
}
}
Using only one thread would allow me to avoid headaches from dealing with concurrent use of the same datastructure used by both the "receive datagram" and "update table". Is this doable?
|
|
|
|
|
If you can 1) get the UDP events without blocking on the receive, 2) send UDP packets without blocking, and 3) use CreateWaitableTimer, then I think this would be possible. If you are constantly getting receive events, then you will also need to maintain an internal record of when you most recently checked the table, so that you can also automatically check it every 2 seconds even if the CreateWaitableTimer has not expired, or if you miss its event because your thread was busy servicing many receive events.
In other words, you need the 2 second timer in case there is no activity, but you also need to know when 2 seconds have gone by in case you are busy otherwise - you still need to check your table periodically. If you don't need high precision on that 2 seconds, then you can use some GetTickCount() math to track elapsed time.
|
|
|
|
|
I've been trying to find a way to wait for multiple events, both timer and network events at the same time. It looks like I would need a function that does the job as WaitForMultipleObjects and WSAWaitForMultipleEvents at the same time. Or is it possible to use the WSAEVENTs with WaitForMultipleObjects?
I'm not 100% sure that I understood the bit about missing events. If I've understood it correctly events are signaled via flags and you can wait for these flags to be signaled via, for example, WaitForMultipleObjects.
If the timer expires it should set its flag and if I do:
loop {
e = select_event_from_all_signaled_events()
}
I would eventually see that the timer event was signaled (I might catch it later than I intended but it shouldn't be lost). I only need to receive timer events every 15 seconds or so and precision is not important (if it differed by 2 second it would still be no problem).
|
|
|
|
|
I am not sure if the WSA events can be used in the WaitForMultipleObjects.
The reference to 'missing' timing events could have occurred if your thread was so busy processing network events that it did not 'time out' right at 2 seconds, but rather saw the timer event some time AFTER it had finished processing network events. However, since your processing of 'timers' is not so critical, that part would probably work fine.
|
|
|
|
|
It was as I thought then. I expect for the program to be waiting most of the time and receive an UDP message every 30 seconds or so and send one every 60 seconds or so.
I'm suspecting that it isn't possible to construct and entirely event passed (passive) solution for this problem. If I can't find some callback mecanism for both the network and timing events that is.
|
|
|
|
|
Given this situation, I would be inclined to create two threads. One that waits on the WSA Events and the second one running the timer and waiting on regular events. You can always communicate between the two threads when you receive a UDP packet so the timer thread does not improperly update information for a UDP packet you already processed.
For example, the WSA thread would communicate with the timer thread. If the timer thread times out and then scans the packet information, it can skip the processing for UDP data recently observed. Also, the WSA thread could set 'regular' events that can trigger activity in the timer thread. It seems more problematic to go in the other direction. If you use MsgWaitForMultipleObjects in the timer thread, you can use PostThreadMessage to send messages to the timer thread from the WSA thread.
|
|
|
|
|
I have a toolbar on SDI frame. I am able to add the buttons onto the toolbar at run time. I want to draw line or draw rect on that buttons. I don't want to insert a BMP into it.Can anybody let me know how I can draw line or draw rect on that buttons at run time. Thank you in advance!!!
|
|
|
|
|
All projects in VC6 seem to have MBCS defined by default.
With MBCS, a logical character can be 1 byte or 2 bytes.
therefore it is very important that we do not use _TCHAR *p; p++
but use _tcsinc(p).
But in most of the projects I have seen, I have not seen anyone using
_tcsinc anywhere. now dont say you dont use p++ either, its little hard to believe.
So how many of you use _tcsinc? If you dont, do you think it is not necessary? is it because your program will never run into multibyte character strings?
a google search on "_tcsinc" yielded only 356 results!
pliss to clarify. Thanks.
|
|
|
|
|
it's the first time i ear of _tcsinc()...
my programs use MBCS and I use TCHAR... you just have to #define _UNICODE (or not).
i don't really understand what is your problem with TCHAR and what _tcsinc() gives more...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
1. You should read: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/msdn_mbcssg.asp[^]
2. You either define _MBCS or _UNICODE, but not both.
3. If you define _MBCS, then the above doc tells you why you should use _tcsinc and not p++. with p++, you may end up in the middle of a 2 byte character. So you should use the macro _tcsinc, which increments p by 1 or 2 depending on whether the character at p is a 1 byte char or 2 byte char.
4. My only worry is that this document is 10 years old, so I am not sure any changes have gone into the compiler for automatically using _tcsinc for p++, but that is unlikely(or I dont know, you folks here should tell me that).
back to you guys.
|
|
|
|
|
MSDN is regularly updated, so, even if this article is dated from August 1995, it is still going...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Flace wrote:
a google search on "_tcsinc" yielded only 356 results!
You should also search for CharNext, the win32 API equivalent of the C runtime function _tcsinc.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
Honoured as one of The Most Helpful Members of 2004
|
|
|
|
|
okay, that gives more results. perhaps it is more known to people than the _tcsinc.
Do you use either of these in your programs?
|
|
|
|
|
I missed an important question in the previous post:
if you dont use _tcsinc, you are either assuming the string have 1 byte characters or your program will go wrong someday. And if you assume your char is 1 byte, then using _TCHAR doesnt make sense. You can use just the char as well. What do you folks say?
|
|
|
|
|
If you use TCHAR, you are IMPLYING your string can be UNICODE if a UNICODE build is made. If your string must ABSOLUTELY be 'single byte characters' then use 'char' and if it must absolutely be UNICODE, then use wchar_t or WCHAR. You can potentially convert back and forth with MultiByteToWideChar and WideCharToMultiByte.
If you want your 'single-byte-character' processing to be internationalized, then at least compile for MBCS and use the 'mbs' for every hard-coded 'char' string and the '_tcs' functions on every TCHAR string. You get BIZARRE results if you hard code to an 'mbs' function against a TCHAR string and then commpile for UNICODE. Now you would be passing a wide-character string to a function expecting multi-byte character string.
Summary:
char -> use str or (preferably) mbs functions
TCHAR -> use tcs functions (compile either way)
WCHAR or wchar_t -> use wcs functions
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
