|
Hi,
I'm trying to write a simple UDP client application which receives UDP
packets from a server, each the size of 384 bytes. Unfortunately, I'm
encountring what seems to be client-side packet loss, which gets only worse
when multiple threads are added to the application. This is not a result of
high CPU usage, since the CPU usage is only a few percent. I can only assume
that the packet loss is a result of context switching done by the OS, and my
application not being able to receive the packets on time.
I'm using VC++ on win2k, and the winsock2 functions in the platform SDK to
create a socket and receive UDP packets from a specified port. I've tried
setting the process & thread to time critical, which does have an
improvement, but the packet loss continues.
Is there any way to avoid client-side UDP packet loss ??
Ideas / code examples would be greatly appreciated !
Danny
|
|
|
|
|
You probably don't want this answer but...
Yes, it's called TCP.
Before flaming me consider the U in UDP. It's there for a reason.
If you can't deal with lost packets (by means of reckoning, ignoring, application-initiated retransmissions and so on) go ahead and use TCP.
Ofcourse you can try to minimize lost packets but since you never can be sure you got em all, why bother?
Just my 2cents...
"Well I'm just a hard working corporate slave, my mind should hate what my body does crave.
Well I'm just a humble corporate slave, driving myself into a corporate grave"
Corporate Slave, SNOG
|
|
|
|
|
Before flaming me consider the U in UDP. It's there for a reason,
U stands for "user", I don't see how this is relevant 
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
It's the answer to the question:
Who will implement everything lacking to make this really usefull?
"Well I'm just a hard working corporate slave, my mind should hate what my body does crave.
Well I'm just a humble corporate slave, driving myself into a corporate grave"
Corporate Slave, SNOG
|
|
|
|
|
UDP is connectionless, so it's always possible you will lose packets. Try to use TCP sockets, or build some kind of protocol (using UDP) to avoid packet loss. You can play with the network card driver buffer settings, or using bigger packet size, or decrease the frequency. And if you are not using a real-time OS, you cannot be sure the OS will store all the incoming packets.
Zolee
|
|
|
|
|
UDP is connectionless, so it's always possible you will lose packets. Try to use TCP sockets, or build some kind of protocol (using UDP) to avoid packet loss. You can play with the network card driver buffer settings, or using bigger packet size, or decrease the frequency.
If you are not using a real-time OS, you cannot be sure the OS will store all the incoming packets. Like a driver will run on higher priority than your process, and it's possible you'll lose packets.
Zolee
|
|
|
|
|
Note that if sending a UDP messages from several threads and before ARP resolution is done (because ARP entry has expired or is the first message sent), it will cause some (or all?) UDP messages to be lost.
This is (according to MSDN) due to the fact that there can only one pending ARP-reply per host-IP. Sorry I cannot find the ref. at the moment.
Remedy: call SendARP() before sendto().
Gisle V.
"If you feel paranoid it doesn't mean they're not after you!" -- Woody Allen
|
|
|
|
|
I've created an Edit box like this:
wndCmdEdit = CreateWindow("edit",
NULL,
WS_CHILD | WS_VISIBLE |
WS_BORDER | ES_LEFT | ES_MULTILINE,
5, 130,
385, 20,
hWnd,
(HMENU)IDC_MAINWNDEDIT,
hInst,
NULL);
But when I write text to it with "new line" char it adds a | instead of new line!!
Why??
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
try \r\n
Gary Kirkham
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
|
|
|
|
|
Because the newline character is not enough. It needs to also have a carriage-return character ('\r'). So the proper way to insert new lines is with "\r\n".
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
It's not the first time that I post this message. Look like nobody can help me...
I want to draw a transparent bitmap into a Dialogbar.
Here what I tried:
this is in my dialog bar class...
BOOL myDlgBar::Create(CWnd* pParentWnd)
{
if(!Create(pParentWnd, IDD_DLG_POSROOT, CBRS_RIGHT, IDD_DLG_POSROOT))
{
return 0; // fail to create
}
else
{
COLORMAP clr; //used to chnge my black color in my bitmap to white color
clr.from = RGB(0,0,0);//black
clr.to = RGB(255,255,255);//white
m_SLogo.Create(_T("my static"),WS_CHILD|WS_VISIBLE|SS_BITMAP|SS_CENTERIMAGE,
CRect(9,10,209,78), this, IDC_LOGOPOSROOT);
m_SLogo.SetBitmap(::CreateMappedBitmap(AfxGetInstanceHandle(), IDB_LOGO, 0, &clr, 1) );
return 1;
}
}
with CStatic m_SLogo;
IDC_LOGOPOSROOT is my picture class object in the resource editor with "frame" option
IDB_LOGO is my id of my bitmap in the ressource editor
IDD_DLG_POSROOT is the id of my dialog in the ressource editor
The result of this is that I can see my bitmap in my dialog bar but the black didn't change to white...
thanks
Everything's beautiful if you look at it long enough...
|
|
|
|
|
i suggest:
1. creat a blank application and only test the fuction
or
2. use "find in file" to search the function in msdn samples (source are in CD).
i only remember that the function is very simple.
good luck
includeh10
|
|
|
|
|
If I have:
int Multiply(int iA, int iB)<br />
{<br />
int iProduct = iA * iB;<br />
return iProduct;<br />
}
How can I test for multiplication overflow, the situation in which the correct result of iA * iB requires too many bits to fit into iProduct?
|
|
|
|
|
One method is to do the multiplication using __int64s and then testing for overflow.
__int64 result = __int64 (iA) * __int64 (iB);
if (result != (int) result)
However, this assumes int isn't an __int64.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim's is probably the simplest method.
You can also opt for trapping these kinds of problems using structured exception handling. In your case it looks like an Integer Overflow exception (0xC0000095).
Do a search for "_try" in MSDN and take a look at this article[^].
[edit]
Yet another option is to put the code inside a try/catch-all block:
int Multiply(int iA, int iB)
{
try
{
return iA * iB;
}
catch (...)
{
}
}
[/edit]
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
How do I enable integer overflow trapping? It doesn't seem to be on by default.
Eddie Breeveld
|
|
|
|
|
I guess this could do:
inline bool mult_overflow(int a,int b)
{
return a!=0 && (a*b)/a!=b;
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
int mult(int iA, int iB)
{
int product = iA * iB;
if(iB != 0 || product / iB != iA)
throw MathException;
return product;
}
I believe this works.
|
|
|
|
|
I always used CWnd when working with MFC, never really used HWND as I never really programmed fully Win32 applications.
Is there an advantage to use HWND to keep objects in containers ( for example ? ) instead of CWnd* ?
std::vector<HWND> hwndVector;
std::vector<CWnd*> cwndVector;
Thanks.
Max.
|
|
|
|
|
As for the efficiency, none at all (both types of objects occupy the same space). Using HWND will tend to make things more complicat, specially in multithreaded code, where it is not easy to retrive the "true" CWnd attached to a given HWND. So, I'd say you're better off using CWnd *s.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
Using HWND will tend to make things more complicat, specially in multithreaded code
But if you're passing Window handles between threads you have to use HWNDs as the CWnd/HWND mapping doesn't go across the thread boundary properly.
|
|
|
|
|
It is the mapping HWND->CWnd that does not hold across threads, not the other way around. Handling a CWnd object from a thread other than the one which created the CWnd is just fine (modulo concurrency problems).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
If you have a single-threaded application storing CWnd* is more practical, easier to use.
You CANNOT use the CWnd* in a different thread, than the thread, where the given CWnd* was created. What you can do is you pass the HWND for the given window to the thread, and in that thread you create your CWnd* using CWnd::FromHandle(hwnd), after that, you can use this CWnd* in this thread. So it's more practical to store HWND in this kind of environment.
I could give you some examples, when you could use CWnd* in a multithreaded application, but it's very wrong.
Zolee
|
|
|
|
|
You CANNOT use the CWnd* in a different thread, than the thread, where the given CWnd*
I do not agree with that. Can you give some example in which using a CWnd * across threads is wrong and doing the same with a CWnd * obtained via CWnd::FromHandle is right?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
How can I get the app Path without geting the app name?
\Larsson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
