|
UDP is the wrong protocol to use for file transfers. There is no guarantee that packets will even arrive at the destination.
|
|
|
|
|
I don't agree that UDP is "wrong". It depends on the application.
For example UDP is massively better than TCP if you want to multicast to multiple hosts.
But yes, you do have to handle transmission problems yourself - you don't get return codes from the APIs that you do with TCP.
It is also difficult to make UDP secure - then again TCP isn't secure on its own (needs a security layer such as SSL).
cheers,
Neil
|
|
|
|
|
Hello Neil,
Thanx for your timely suggestion
Can i know exactly further how should i go ahead.
I want to send a file through UDP.
I am aware of it using in TCP.
Can i know how it is done in UDP
Thanx in Advance
Girish
Software Developer
|
|
|
|
|
As already mentioned, it isn't a good idea to do file transfer over UDP given it is connectionless. Doing it over TCP (with or without a security layer) will be easier and more reliable.
I believe that the TFTP system is designed to transfer files over UDP. Although TFTP isn't really used these days, I think from memory that the process of remote booting a workstation uses it, and transfers the boot image from the server to the client over UDP.
Therefore, if you absolutely must transfer a file over UDP and have no other options, see if you can find an open source TFTP program to give you some pointers on how to do it. Most likely you will find the code to be *nix oriented though. You may even be lucky enough to find a TFTP library you can use as well.
------------------------
Luke Lovegrove
------------------------
|
|
|
|
|
How to DoModal a winodw on all of the othere programs; winodws
|
|
|
|
|
|
Use extended style WS_EX_TOPMOST while creating dialog.
|
|
|
|
|
Hi,
assume i want to create a dynamic array of bytes(or any other data type) (unsigned char *p = new unsigned char[100]; ), how can i ensure that it is aligned to a 32-bit boundary?
|
|
|
|
|
#pragma pack(push, 4)
unsigned char* p = new unsigned char[100];
#pragma pop()
will do it, I think. (I'm not sure how is new affected by pragma pack).
Nuclear launch detected
|
|
|
|
|
|
I am afraid that #pragma pack will have no impact on the above code, its primarily used to align members of a structure, such as this:
#pragma pack(push, 1)<br />
struct myStruct<br />
{<br />
char szTmp[20];<br />
short iIndex;<br />
...<br />
}<br />
#pragma pop()<br />
|
|
|
|
|
Yes, you'll probably right. What am I saying, for sure you're right.
Then the only way I can think of is to align the allocation size to DWORD.
There was a ALIGN_DWORD (or DWORD_ALIGN) macro or something - anyway was something like (memory quote)
((p + 3) & ~3)
This one
#define ALIGN_CLUSPROP( count ) ((count + 3) & ~3)
is from ClusApi.h, but the idea is the same.
In this way the buffer will not allocate, say, 102 bytes, but (102 + 3) & ~3 = 105 & ~3 = 104.
Nuclear launch detected
|
|
|
|
|
True, hopefully this will work.
According to the C++ standard:
"The C++ standard guarantees that all memory allocated via operator new or malloc will be suitably aligned for any possible kind of object you might want to store in it, which means that operator new and malloc have to respect the strictest possible type alignment requirement of the native platform."
so just using new with the correct size should work
|
|
|
|
|
I think pragma pack doesnt work with dynamic variables, objects. I cant find anywhere on the internet about aligning dynamic objects using pragma pack or any other way. Or is it because dynamic objects are aligned by default to 32-bit boundary?
|
|
|
|
|
I am not sure you will be able to do this, its up to the Windows Memory manager as to where the memory will be allocated.
Why do you need to do this anyway ?
-- modified at 4:31 Wednesday 10th January, 2007
You obviously cannot use #pragma, but the new keyword performs byte alignment for you anyway so just try that.
|
|
|
|
|
I'm doing image processing, and i need to maximize the performance of a real-time program. I'm using intel's integrated performance libraries, which recommends that the allocated data must be aligned to 32-bit boundary. Not aligned data will be processed multiple clock cycles slower. Although the library does provide its own allocation function (ippiMalloc_8u.. ), but i was wondering how to do it myself.
Any ideas?
|
|
|
|
|
uus831 wrote: 'm doing image processing, and i need to maximize the performance of a real-time program. I'm using intel's integrated performance libraries, which recommends that the allocated data must be aligned to 32-bit boundary. Not aligned data will be processed multiple clock cycles slower. Although the library does provide its own allocation function (ippiMalloc_8u..), but i was wondering how to do it myself.
Any dynamic memory returned from malloc, GlobalAlloc, etc. is properly aligned. You need to worry about alignment only when you write your own allocator.
|
|
|
|
|
As mentioned previously and also by Sceptic Mole , just use the new operator, it correctly aligns data based on the data type you specify.
Also be very careful when optimising code, have you any indication that that part of your code is actually slow and requires optimising - have you tried a performance analyser ?
|
|
|
|
|
Yes, you are right. But the thing is that, i want to create a new array of char, but align it to int, not char (align to 32-bit, not 8-bit) which is the default behavior as you have mentioned.
I time the code segment (of my worker thread) by using QueryPerfCounter, and i need it to work within a real-time limit of 40ms (25FPS).
|
|
|
|
|
|
Thanks, i'll try that. I think this is what i need.
|
|
|
|
|
I would like to "serialize" an ICON, i.e. express it as a simple sequence of bytes
that could be written/read from a database.
A .ico file could be treated as the serialization of an ICON, but that would probably be wasteful, as a .ico file can store icon images for a variety of icon sizes, and I am just interested in one device (32x32 as it happens).
An ICONINFO structure requires two BITMAPs, one for the mask and one for the color bits.. which is a bit messy.
Is there a simple way of serializing one ICON into ONE blob ?
cheers,
Neil
|
|
|
|
|
Why not just save the color bitmap and create a mask at runtime? You could go further since all your icons will be the same size, save only the array of bits from the color bitmap, and add the bitmap headers at runtime.
|
|
|
|
|
That's a good idea.
How do I get at the BITMAP stucture, starting from an HICON ? I saw GetIconInfo(), GetBitmapBits(), but the latter function doesn't seem to tell you how much memory to allocate - so I can't see how I can use it !
Presumably it is simple to create the mask BITMAP from the color BITMAP?
cheers,
Neil
|
|
|
|
|
Try to use FindResource, LoadResource, SizeofResource (size in bytes) and LockResource (get the pointer to the first byte).
Probably you'll have to work with #pragma pack(1), but I'm not sure.
Anyway, SizeofResource+LockResource will get you a pointer to a byte array and its size; you can simply get the byte array and store in a blob (perhaps also size should be stored as well).
HRSRC hrcIcon = FindResource(hExeOrDll, MAKEINTRESOURCE(IDI_YOURICON), RT_ICON);
HGLOBAL hgl = LoadResource(hExeOrDll, hrcIcon);
LPVOID pvIcon = LockResource(hgl);
DWORD dwSizeInBytes = SizeofResource(hExeOrDll, hrcIcon);
#pragma pack(push, 1)
BYTE *pbIcon = (BYTE *)malloc(dwSizeInBytes * sizeof(BYTE));
CopyMemory((PVOID)pbIcon, pvIcon, dwSizeInBytes);
#pragma pack(pop)
free(pbIcon);
Nuclear launch detected
|
|
|
|