|
It is very similar, except that datagrams (UDP messages) have a maximum size, and there is no guaranteed delivery or sequencing/ordering of data.
With TCP, if you send 128KB of data with a single call, internally it will be broken up (if necessary) into smaller packets (either on your system or possibly further down the network) that will be reassembled on the receiving system.
With UDP, IIRC, if you try to send 32KB with a single call, only a certain amount of it will be sent (something like 1500 bytes, I think). You will need to break up the data yourself into packets and send them one at a time. Additionally, if you send 5 packets in a row (1,2,3,4,5), they may arrive on the other side out-of-sequence (1,2,4,5,3), or some may not make it at all (1,3,4,2 but no 5th datagram).
Sending multiple-packets of data via UDP often requires that you implement your own packetizing logic so that you handle lost or out-of-sequence packets.
Broadcast, point-to-point, point-to-multipoint or multicast has nothing to do with your using TCP or UDP, IIRC. You can data using either style to a broadcast address (i.e. xxx.xxx.xxx.255), or to a multicast address (multicast router, for example).
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: Broadcast, point-to-point, point-to-multipoint or multicast has nothing to do with your using TCP or UDP, IIRC. You can data using either style to a broadcast address (i.e. xxx.xxx.xxx.255), or to a multicast address (multicast router, for example).
I'm currently doing some research on broadcast and multicast, as we plan to use it in one of our projects. All documents I found so far claim that broadcasing and multicasting require the use of UDP. This does make sense to me, as TCP requires an established connection and for broadcasing and multicasting you don't even know to how many recepicients you are talking.
Regards,
Tim
|
|
|
|
|
Tim Paaschen wrote: All documents I found so far claim that broadcasing and multicasting require the use of UDP. This does make sense to me, as TCP requires an established connection and for broadcasing and multicasting you don't even know to how many recepicients you are talking.
Interesting... I think that makes sense for things like using PING to try to ping a broadcast address, but not for multicast that is supported by the network hardware. Since one or more routers could handle connetions to multiple clients, and since the connections are one-way, connection or connection-less would not matter - clients would subscribe to the 'cast by subscribing to the multicast server. But then again, I have not been close to multicast for some time now, so my memory of it may be faulty.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Girish601 wrote: I have worked previously on TCP,but not on UDP.
As far as previous post is concerned,somebody said that it is similar
as creating Socket and Sending it using IP and Port.
No big difference. It still requires port & IP.
Girish601 wrote: I hope in UDP you are sending on a Broadcast IP and port,so how to do it.
It's not "in UDP we broadcast". Broadcast is done if we want to. For sending files I dont think UDP would be the best option. But in LAN environment, it's success rate is 99%. The main difference is, it's connectionless protocol that means it doesn't maintain any connection between the server & client. Just "push" the data and "get" the data. No connection path is set up in between. let me give you a link ..please wait.
Code-Frog:So if this is Pumpkinhead. Time for him to run and hide. It's an interesting thought really.
|
|
|
|
|
Hi, I have a question:
Let's say I write a program in C++ and then set a certain file extension to "open with" the program I wrote. When I double-click on the file, and it opens up my program, what happens to the file data? Basically I just need to get the data from that file so I can use it in my program, the same way in which the contents of a text file will appear in notepad if you double-click on a txt file (and have notepad set as your default text editor, of course).
Thanks~
kr
|
|
|
|
|
The program that is launched gets the path to the file that was double clicked on as argument.
If you're using MFC that means you get the file path in CWinApp::m_lpCmdLine.
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
I'm not using MFC in this program, so what variable is that argument stored as? I'm assuming it's the same as getting a command line argument in UNIX for instance but I don't know where that string is or how to retrieve it when using a Windows GUI.
Thanks!
KR
|
|
|
|
|
If you're writing a windowed application the you have the path inside WinMain:
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
lpCmdLine will contain the path of your file.
On the other hand, if you have a console application, then the path of the file will be in item 1 of argv[] argument of main.
int main(int argc, char* argv[])
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Oh duh, I didn't even notice the lpCmdLine there in the WinMain. Thanks, I'm all set!
KR
|
|
|
|
|
KellyR wrote: I'm not using MFC in this program, so how do I process that argument?
Well, what are you using then?
You say that using "Windows GUI", but what do you mean by that?
If you're using another framework then the documentation for that framework must have some information about how to get hold of the program arguments. So if you're using any kind of framework you're basically the best suited for answering your question.
If you've implemented the main function you can get the program arguments as desccribed here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
Roger Stoltz wrote: If you're using another framework
In fact you don't need a framework to build up a Windows GUI application.
(for instance using Visual Studio 6, you can choose Win32 application to start a full featured GUI application without using MFC, it's the hard way, but it's there...).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: In fact you don't need a framework to build up a Windows GUI application.
Of course you don't.
You can always start with WinMain.
I even provided information about how to do it the old way if he was creating a console application: the link.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
Roger Stoltz wrote: I even provided information about how to do it the old way if he was creating a console application: the link.
He actually needed info about WinMain, not main.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: He actually needed info about WinMain, not main.
That was your guess, which turned out to be right. 
But nothing in the first post made that clear.
If you take a look at David's reply below he's given an answer to exactly what the OP asked for, since he wanted to know "what happens to the file data". 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
Actually it wasn't a guess (was exaustive of my knowledge):
first I suggested (like you, I think) MFC m_lpCmdLine, then argv[1] of console apps and lpCmdLine of WinMain.
Roger Stoltz wrote: If you take a look at David's reply below he's given an answer to exactly what the OP asked for, since he wanted to know "what happens to the file data".
I agree. But some times these MVPs seem to be a bit rude with newbies like me!!!;)
-- modified at 14:09 Wednesday 10th January, 2007
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Part of effectively answering a question lies within determining what information the questioner is truly looking for. This is why I included an explanation in my original post about what I needed the file data for (just in case my question, 'what happens to the file data' was not actually what I needed to know). As we all know, sometimes the questions people ask on this site are unclear, or directed towards the wrong problem.
I do strive to make my questions as clear and understandable as possible, as well as post effective and comprehensive answers to questions that I can help with.
Thanks to all of you for doing your best to effectively answer my question. My program now does what I need it to do.
KR
|
|
|
|
|
KellyR wrote: My program now does what I need it to do.
Nice to hear (read?). ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
KellyR wrote: Part of effectively answering a question lies within determining what information the questioner is truly looking for
This is absolutely true.
However, sometimes the poster is unaware of a better solution for a problem that he or she is trying to solve, or the poster has misunderstood something at a conceptual level. This is often hard to get at and that's why I sometimes get a little provocative trying to make people think and maybe rephrase their questions.
I know it can be a thin line before I offend people, but my intentions are to help to the best of my knowledge and I think that goes for anyone who contributes to this community. If that's worth something, is for the person with the question to decide. 
It's even harder when we have cultural differences, different experiences and many of us don't have english as our native language. Often we have to guess and sometimes we are wrong. Thus I think it's better to answer in way that one can understand that there are many different ways to solve a problem and to which is best might require more information.
Hmm, close to Lounge material... Sorry...
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
KellyR wrote: Thanks to all of you for doing your best to effectively answer my question. My program now does what I need it to do.
You're welcome! 
KellyR wrote: Part of effectively answering a question lies within determining what information the questioner is truly looking for. This is why I included an explanation in my original post about what I needed the file data for (just in case my question, 'what happens to the file data' was not actually what I needed to know). As we all know, sometimes the questions people ask on this site are unclear, or directed towards the wrong problem.
I do strive to make my questions as clear and understandable as possible, as well as post effective and comprehensive answers to questions that I can help with.
Don't worry about!!!!
Sometimes we like to have small debates............
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
If you do not have access to the argument count or to the arguments themselves, you can make a call to ::GetCommandLine() to get a TCHAR-style string containing all of the arguments.
If you need access to the arguments using a C-style array of string pointers, you can use the CommandLineToArgvW(...) function to do that (note that you will have to do any necessary conversion to/from Unicode yourself).
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Thank you for the useful information. In this case I have the argument in WinMain but this is good to know in case I'm using something else.
KR
|
|
|
|
|
KellyR wrote: When I double-click on the file, and it opens up my program, what happens to the file data?
Nothing, by default. The shell simply lets your program know the name of the file you requested to open. It's up to your program to actually do something with it.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Is it possible with a class derived from CDialog? Can I do some SetMinimiseButtonPos() or SetCloseButtonPos() tricks somehow?
And another question about titlebar, is it possible to center titlebar's text?
Thanks in advance;)
|
|
|
|
|
PatrykDabrowski wrote: Is it possible with a class derived from CDialog? Can I do some SetMinimiseButtonPos() or SetCloseButtonPos() tricks somehow?
And another question about titlebar, is it possible to center titlebar's text?
You will have to draw the whole title bar yourself, hide all the buttons and provide all default functionality yourself, See this article[^]
mostly applications just hide the title bar and paint a new title bar on the window area itself.
If you think you can than you can, if you think you can't you are right.
|
|
|
|
|
What is the simplest way for doing this? All i want is to get rid off that annoying confirmation dialog stating "Unidentified Publisher" and asking to confirm launching, because on any other grounds, my app is fully compitable with Vista.
I tried to embed the following manifest, i.e. added the trustInfo part, but it doesn't seem to have changed anything, need some code signing crap...sorry.
Anyone? Please!!!!
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="5.1.0.0"
type="win32"
name="ACTWin.exe"/>
<description>ACTWin</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="highestAvailable" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="x86"/>
</dependentAssembly>
</dependency>
</assembly>
|
|
|
|
|
Signing has nothing to do with the manifest. You need to buy a code signing certificate, and use that to sign the EXE.
Also, unless your program does administrative tasks, you should use level='asInvoker'
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
