Inline. Well, I suppose so, that the multicast socket would be closed at system shut down. but I still dont understand why you would want to close it just after sending a message? I do not want to close it immediately. I only want to close it when it is no longer needed for the UA. For ex: A user wishes to join a conference, and gives an address to the transport, which is a multicast address. So the transport layer creates a multicast socket joins the group & sends the message. The user is now part of the group. After sometime the user wishes to come out of the conference, so initiates a BYE. This is when I should be closing the socket. But I don't know how to implement this, since in every other case, the sockets are closed either immediately or after the expiration of a timer.
In the case of unicast, you are not reusing the connection opened, and therefore you have to specify a port in the via header that is different from the local port of the socket used to send out the message, isn't it? Yes. And in any case they are connection-less. regards Salva On 31 May 2002, at 15:50, Vijay S Kamath wrote: > If we send a request over UDP, the response is sent to the > address/port specified in the 'sent-by' field of the VIA(which is > where I would be listening for UDP), hence I can create a socket by > binding to a randomly selected local port, send the message & close > the socket. The response would come at the address/port specified in > my VIA. Thus I'm freeing up all the resources used by that socket. But > since I cannot close the socket for multicast, and I will also not > know when to close it, this resource would be freed only at system > shutdown. Am I right? > > Regards... Vijay > > -----Original Message----- > From: Salva Rey Calatayud [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 31, 2000 2:47 PM > To: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] Multicast socket query > > > Hi, > On 31 May 2002, at 14:21, Vijay S Kamath wrote: > > > Yes, multicast sockets should be datagram. > > But my question is, when do we close this socket? In case of a > > normal UDP transport, we can simply send the message & close the socket, > in this case you won't receive the messages that might be sent > back to you, will you? you need to be listening that socket, even if > on UDP if you want to receive messages back. Your concern is > about what the transport layer might do, if I got you right. I don't > think the transport layer is gonna close what it would be > ServerSockets (in Java), but only client sockets (or Sockets, called > there). Therefore, even if all TCP connections (sockets) are closed, > it will still keep the ServerSockets listening for incoming > connections. This is regarding TCP. For UDP I think the transport > layer takes no action on closing DatagramSockets > > but in > > case of multicast, we can't close the socket since we need to join > > the multicast group & listen for any messages that are posted into > > the group. > > > best regards, > Salva > > > Vijay > > > > -----Original Message----- > > From: Salva Rey Calatayud [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 31, 2000 2:21 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] Multicast socket query > > > > > > Hi, > > > > I think that multicast sockets only work on UDP, does your > multicast > > socket work on TCP ? > > > > regads > > Salva > > > > On 31 May 2002, at 8:59, Vijay S Kamath wrote: > > > > > > > > > I'm reposting this query... > > > > > > I've a doubt on the transport layer functionality of bis-09. > > > According > > > > > to bis-09, persistent connections can be closed after 64*T1 secs, > > > hence all TCP sockets will get closed automatically after some > > > amount of idle time. But if we create a multicast socket, we also > > > need to join the multicast group. When can we leave the group and > > > close the socket? Can the transport layer decide to close the socket > > > > after some amount of idle time same as in case of TCP? > > > > > > Thanks in advance. > > > > > > Regards... Vijay > > > > > > > > > > > > > > > > > > > > >
**************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ****************************************************************************************
