Re: The best way to wait for something to happen

Be careful of UDP connections. Packets that are sent using UPD are not
guaranteed to be received. In fact, even if they are received, they may
arrive in a different order than you originally sent them. A simple
example might be as follows:
Sent: The quick brown fox jumps over the lazy dog.
Received: over the The quick brown fox jumps dog.
This can be coded for using a method of including a sequence number in your
packets, and then reordering them once they have all arrived.
You will also need to code for packets that never arrive. It is easier to
use TCP which already handled both of these issues.

The other thing you will want to think about is how you know the entire
message has arrived. This can be achived with a few methods:
1. Make all packets the same size.
2. A terminating character at the end of the transmission.
3. A header block on the front of each packet that includes the size of the
data to be received.

There are alot of resources on the net for doing this, especially is you can
read VB.
I referred to this site alot when I was first starting out.
http://www.vbip.com/

Good Luck
Dan





"Jeff Grippe" <jgrippe@xxxxxxxxxxx> wrote in message
news:12fttoqe7oe2jf8@xxxxxxxxxxxxxxxxxxxxx
Dan,

Thanks for the feedback. I am trying to communicate between applications
running on my LAN using UDP since it is a "connectionless" protocol.

I am always happy not to re-invent the wheel, however.

What do you recommend that would allow applications running on a LAN to
talk to each other?

I was going to use the WinSock ActiveX control and UDP protocol.

When one application wants to talk to another one I was going to send a
message to the other application to make sure it is awake and able to
answer. That was my "HELLO" message. If the application did not answer the
"HELLO" then I would assume that it was not running or not available. If
it answered the "HELLO" then I could send my message and wait for a
confirmation.

I suppose I could just send the message and wait for the confirmation and
not bother with the "HELLO".

What do you recommend for messaging between applications running on
various workstations on a LAN?

Thanks Again,
Jeff
"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:O8JWWAd0GHA.2036@xxxxxxxxxxxxxxxxxxxxxxx
The protocols that communicate over TCP/IP (usually http/https) are
already
send/receive. That is, every send gets a response (or a built-in
timeout).
By far the easiest way to handle them is with MSXML.

What you're describing actually sounds a lot like a webservice, to use
the
new-fangled fancy-speak name for it. It's a basic pitch/catch approach
that's existed since the first computers were networked.

You haven't given enough information for any kind of input.

Dan

Jeff Grippe wrote:
Hello and thanks in advance for the help.

I am coding a form that will be sending and receiving TCP/IP
messages. I would like to do the following:

Send a HELLO message to the other side
Wait for a reply to the HELLO message with a time out after 3 seconds
(or something parameter driven).

My current thinking is:
Send the HELLO message
Activate a TIMER control
If a reply is received, deactivate the timer.
If the timer event fires, my reply timed out.

Does this seem like the best way to do this?


Thanks again,
Jeff






.

Relevant Pages

  • Re: PeerGroupSendData - UDP or TCP?
    ... is TCP (not UDP) when calling PeerGroupSendData. ... Being built on TCP, all the packets will be gaurenteed to be delivered, ... The ordering at the receiving end is not gaurenteed. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Determining if it is "safe" to send UDP packets
    ... for receiving Udp data. ... I'm receiving from a camera lines of data at 55 Hz. ... the next packet hits the wire. ... Another problem with TCP is its assumption that a lost packet is due to ...
    (microsoft.public.win32.programmer.kernel)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets
    ... Imagine that fast CPU sends a burst of UDP ... spirit of UDP standard should do in that particular case? ... blocking a clling thread until the NIC hardware ... reads one or more packets from socket's send buffer freeing up space ...
    (comp.os.linux.development.apps)
  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
Quantcast