C / C++ / MFC

10-Jan-07 6:11

Ha, that one I didn't know about! Rose | [Rose]

Thanks for the info, PJ. Nice to know. My 5 for that!
This day was not in vain after all, now that I've learnt something new... Big Grin | :-D

"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

Sending File Through UDP

Girish60110-Jan-07 4:14

Girish601

10-Jan-07 4:14

Thanks folks

for your valuable advice of Tcp over Udp.
As far as my requirements are concerned, it demands UDP.
Bcoz the scenario is such that we have to broadcast packets at the same
to n number of Machines across the network.That's the reason i need help
on Sending files over UDP protocol.

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.

I hope in UDP you are sending on a Broadcast IP and port,so how to do it.

Thankx in Advance.

Girish
Software Developer

Roger Stoltz10-Jan-07 4:36

10-Jan-07 4:36

Girish601 wrote:
I hope in UDP you are sending on a Broadcast IP and port,so how to do it.

Create the socket with a call to CSocket::Create and set the nSocketType parameter to SOCK_DGRAM for UDP.
If the socket was successfully created you can use CSocket::SendTo for sending datagrams to whatever address and port you desire since both shall be provided as formal parameters.

If you're not using MFC you can use the raw socket API, but I think you get the picture.

Hope this helps
--
Roger

James R. Twine10-Jan-07 4:50

James R. Twine

10-Jan-07 4:50

   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

Tim Paaschen10-Jan-07 19:42

Tim Paaschen

10-Jan-07 19:42

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

James R. Twine11-Jan-07 13:38

James R. Twine

11-Jan-07 13:38

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!

What happens when I open a file with its "default" program?

Eytukan10-Jan-07 4:56

Eytukan

10-Jan-07 4:56

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.

KellyR10-Jan-07 3:18

Re: What happens when I open a file with its "default" program?

10-Jan-07 3:18

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~

Roger Stoltz10-Jan-07 3:38

Re: What happens when I open a file with its "default" program?

10-Jan-07 3:38

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

KellyR10-Jan-07 4:01

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:01

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!

CPallini10-Jan-07 4:12

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:12

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.

KellyR10-Jan-07 4:18

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:18

Oh duh, I didn't even notice the lpCmdLine there in the WinMain. Thanks, I'm all set!

Roger Stoltz10-Jan-07 4:15

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:15

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[^].

CPallini10-Jan-07 4:21

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:21

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...).

Smile | :)

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.

Roger Stoltz10-Jan-07 4:30

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:30

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.

CPallini10-Jan-07 4:36

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:36

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.
Smile | :)

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.

Roger Stoltz10-Jan-07 4:42

Re: What happens when I open a file with its "default" program? [modified]

10-Jan-07 4:42

CPallini wrote:
He actually needed info about WinMain, not main.

That was your guess, which turned out to be right. Wink | ;)

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". Cool | :cool:

CPallini10-Jan-07 4:54

Re: What happens when I open a file with its "default" program?

10-Jan-07 4:54

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.

KellyR10-Jan-07 5:35

Re: What happens when I open a file with its "default" program?

10-Jan-07 5:35

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.

Roger Stoltz10-Jan-07 5:55

Re: What happens when I open a file with its "default" program?

10-Jan-07 5:55

KellyR wrote:
My program now does what I need it to do.

Nice to hear (read?). Rose | [Rose]

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. Blush | :O

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... Roll eyes | :rolleyes:

Sorry...

--
Roger

CPallini10-Jan-07 8:16

Re: What happens when I open a file with its "default" program?

10-Jan-07 8:16

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! Smile | :)

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............

Smile | :)

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.

James R. Twine10-Jan-07 4:55

James R. Twine

10-Jan-07 4:55

   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!

Re: What happens when I open a file with its "default" program?

KellyR10-Jan-07 5:29