Hi Wilfried,

> WSocket->>MultiCast=true;
> Why is this nececary ?
Well, discovery of UPnP devices require that you multicast an UDP packet to All devices will then unicast a packet back to the
sender. And since my discovery request needed to multicast I assume that I
also needed to set WSocket->>MultiCast=true;

Based on the info in your other posting I now realize that a socket can send
and receive both and so I rewrote my code accordingly. Now, I open the
socket for listening and then use SendTo to send the packet. This seems to
work much better now (no more packet loss). 

However, I still have some questions....

(1) Previously, when I opened the socket with ->>Connect() I got myself a
free port number assigned in WSocket->>Port. This way I didn't have to worry
about which port I could use since I always got a free one assigned.
However, now I open the socket with Listen(); and this requires me to define
WSocket->>Port before calling the Listen(). This makes sense because usually
you know where you want to listen. However, in my case I'm listening for
responses that are sent back to the port I've used for sending the discovery
request. So, any port will be fine. For now, I've just put in a fixed port
number to test my code, but I cannot always be sure if that port is
available. So, I was wondering if it is possible to request WinSock for an
available port that I can use (just like you get a port when using
Connect()) ? 

(2) With the code below I open port 2500 for listening, multicast a packet,
and then listen for 5 seconds before closing the socket. However, if I try
to repeat this sequence a 2nd time, even though I've closed the socket after
listening for 5 seconds, I get following error : 'Error 10049 in function
setsockopt(IP_ADD_MEMBERSHIP) Address not available' when doing the

Here's what I'm currently using...

// Start listening :
// For now using a fixed port value hoping it is available :

// Multicast packet so that UnP devices respond :
TSockAddr MySockAddress;


void __fastcall TMainForm::CloseSocketTimerTimer(TObject *Sender)




-----Original Message-----
Behalf Of Wilfried Mestdagh
Sent: maandag 3 april 2006 8:59
To: ICS support mailing
Subject: Re: [twsocket] THttpCli and UPnP devices

Hello Kris,

> now and then the WSocket->>>OnDataAvailable does not get triggered

This is because UDP is not reliable. If packet is received between the time
you close the socket and set it to listen, then it is trow away.

But wy ?  Just connect, send, and that's all. If someone sends back the
OnDataAvailable will fire. Dont call Close.

> WSocket->>MultiCast=true;

Wy is this nececary ?

Rgds, Wilfried [TeamICS]

Sunday, April 2, 2006, 11:46, Kris Schoofs wrote:

> Thanks Angus. Suggesting to use UDP made it suddenly a lot more 
> comprehensible...

> I've played around with it and I've noticed that all UPnP devices on 
> the network repond with an unicast message sent to my IP on the same 
> port that I previously had used to multicast the UDP containing the
discovery request.

> ** My outgoing UDP Packet :
> Internet Protocol, Src: (, Dst:
> (
> User Datagram Protocol, Src Port: 1059 (1059), Dst Port: 1900 (1900)

> ** An incoming UDP Packet in response to my discovery request :
> Internet Protocol, Src: (, Dst: 
> ( User Datagram Protocol, Src Port: 1900 (1900), Dst Port: 
> 1059 (1059)

> So, what I now do is multicast the UDP Packet, remember the port that 
> was used for sending (WSocket->LocalPort), close the socket. And 
> immediately re-open it but this time for listening on that same port...

> // SEND
WSocket->>Addr ="";
> String MyPort=WSocket->LocalPort;

> This seems to work fine most of the time. However, every now and then 
> the
WSocket->>OnDataAvailable does not get triggered. Any ideas what is 
> this ? Is it OK to close the socket after sending and then immediately 
> open it again for listening on that same port ?

> Thanks.

> Kris

> //--------------------------------------------------------------------
> ------
> -
> void __fastcall TMainForm::WSocketDataAvailable(TObject *Sender, WORD 
> Error) {
> char        Buffer[1024];
> int         Len;
> TSockAddrIn Src;
> int         SrcLen;

> SrcLen = sizeof(Src);
Len    = WSocket->>ReceiveFrom(Buffer, sizeof(Buffer), Src, SrcLen);
if (Len >>= 0) {
>         Buffer[Len] = 0;
>         DataAvailableLabel->Caption =
>             IntToStr(atoi(DataAvailableLabel->Caption.c_str()) + 1) +
>             ": " + Buffer;
> }
> }
> //--------------------------------------------------------------------
> ------
> -

> -----Original Message-----
> [mailto:[EMAIL PROTECTED] On Behalf Of Angus Robertson - 
> Magenta Systems Ltd
> Sent: vrijdag 31 maart 2006 1:54
> To: twsocket@elists.org
> Subject: Re: [twsocket] THttpCli and UPnP devices

>> I'm having a first look at discovering UPnP devices and I was 
>> wondering if THttpCli can be used for this purpose ?
>> Communicating with UPnP devices uses HTTP over UDP (HTTPMU and HTTPU).
>> In order to discover devices you send(post) a HTTP request using the 
>> multicast address on port 1900. All devices should 
>> then respond to this request.

> It's not really HTTP as such, it's just a UDP broadcast that should 
> cause one UDP packet to be returned by each device, each packet 
> containing HTTP formatted data.  Sounds like a one hour project.

> Forget THttpCli, it uses TCP/IP with connections, totally different to
> UDP.   

> Angus
> --
> To unsubscribe or change your settings for TWSocket mailing list 
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be

To unsubscribe or change your settings for TWSocket mailing list please goto
Visit our website at http://www.overbyte.be

To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to