On May 23, 2:53 am, "Arkady Frenkel" <arka...@hotmailxdotx.com> wrote:
> That should be exception in .Net if incorrect parameter set instead tcp in
> this case
> Arkady
>
> "Peter Duniho" <NpOeStPe...@nnowslpianmk.com> wrote in message
>
> newsp.tsrpnexo8jd0ej@petes-computer.local...
>
>
>
> > On Tue, 22 May 2007 23:02:00 -0700, <dean.g...> wrote:
>
> >> What is the difference between the two method of creating a socket?
>
> >> new Socket(AddressFamily.InterNetwork, SocketType.Stream,
> >> ProtocolType.Tcp);
> >> new Socket(AddressFamily.InterNetwork, SocketType.Stream,
> >> ProtocolType.IP);
> >> [...]
>
> > Well...did you *try* it?
>
> > It's true that the only stream protocol supported on TCP/IP is TCP, and so
> > the third parameter in this case should be superfluous. But it's my
> > recollection (possibly incorrect, I admit) that at least in Winsock, you
> > need to provide meaningful values. If you tried, for example, to specify
> > a connectionless, datagram-based protocol when also specifying a streaming
> > socket type, the call to socket() would fail. I would guess the same
> > thing would be true for the Socket class in .NET.
>
> > Keep in mind that TCP/IP is not the only networking protocol out there.
> > In other types of networks it is not necessarily true that the address
> > family with the socket type uniquely determine the protocol. The Socket
> > class, like Winsock, is designed to accomodate a wide variety of networks,
> > and not just TCP/IP. So it stands to reason that even if something is
> > superfluous for TCP/IP, the Socket class would not necessarily allow you
> > to just specify any random value for the third parameter to the Socket()
> > constructor.
>
> > But really, that brings me back to the original question. Did you
> > actually *try* the second example line of code? If so, what did it do? I
> > would suggest that is your best answer right there.
>
> > Pete- Hide quoted text -
>
> - Show quoted text -

Yes I've tried it. The combination is valid, and as far as I can
tell, the socket behaves like an ordinary TCP socket. I thought
perhaps there was some subtle difference between the two that I might
not notice.