Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!touch!todal!virgil From: virgil@todal.touch.com (Virgil Champlin) Newsgroups: comp.protocols.tcp-ip Subject: Re: UDP bind question Message-ID: Date: 8 Feb 90 21:40:14 GMT References: <7391@b11.ingr.com> Sender: virgil@todal.touch.com Organization: Touch Communications Inc., Campbell, CA Lines: 33 In-reply-to: hwajin@ganges.wrs.com's message of 7 Feb 90 22:54:35 GMT In article hwajin@ganges.wrs.com (Hwa Jin Bae) writes: >> In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes: >> I have a question regarding binding to ports in UDP. Is it generally >> acceptable to allow binding more than once to a given port? (I know >> about the SO_REUSEADDR option in sockets, but we have a STREAMS >> implementation which complies with the AT&T Transport Provider >> Interface (TPI) standard, so not everyone is accessing UDP through sockets.) > It doesn't really matter whether you use sockets or TLI interface to access > the UDP/IP. The system calls (whether you use bind() or t_bind()) get turned > into STREAMS messages as they pass through the STREAM heads with types that TPI > multiplexor module understands (in case of bind request it would be > T_BIND_REQ type). Upon receiving such messages TPI multiplexor module will > call protocol specific bind routine to handle the bind request and return > the result of such binding. This sequence of kernel events is identical > for both TLI and socket based requests. This is a bit wrong since the stream head knows nothing about TPI. It also doesn't answer the question "Is it generally acceptable to allow binding more than once to a given port?". I am also unaware of anything in UDP or TPI that prohibits more that one binding, concurrent or not, for CLTS providers. That doesn't mean that some implementations might disallow multiple concurrent binds but I do not know what they would use as a justification. Probably my old standby, "It seemed to make sense at the time.". There is the restriction with TPI that prohibits multiple concurrent binds with a "qlen" greater than zero which effectively disallows multiple concurrent "listens" (in the TLI sense) but this is for COTS, not CLTS providers . -virgil -- Virgil Champlin virgil@touch.com Campbell, CA "I got it, I got it, I ain't got it."