Develop Reference

How to turn on security (Winsock Secure Socket Extensions) for sockets in .net

We are currently working on a simple UDP relay server, which forwards UDP packages from one client to all other clients connected to the same port.
For XBOX One we need to implement Secure Sockets. Unfortunatelly this extension is only available in C++, but our server code is a .net application written in C#.
To make a socket secure in C++ we would simply call:
// Turn on security for the socket.
sockErr = WSASetSocketSecurity(sock, securitySettings, settingsLen, NULL, NULL);
But I have no idea how to do this in C#. I could not find any equivalent for WSASetSocketSecurity in .net. Is this not supported?

Is it possible to use UDP with Web Sockets instead of TCP

I have a C# desktop app and a C# Server console app.
The C# desktop client app uses WebSocket4Net and my C# server app uses Fleck.
Am I right in assuming that it uses TCP protocol. If so, can I get it to use UDP protocol?
The reason I asking this is because I read TCP is slower than UDP because TCP ensures order of packets.
I read this from this article:
Making Fast-Paced Multiplayer Networked Games is Hard

No, WebSockets are based on TCP which in turn is based on IP. UDP is also based on IP, but doesn't have anything to make sure the packets arrive in order or arrive at all. UDP just throws packets at a remote endpoint in the hope someone catches it. It's connectionless, so impossible to use UDP with WebSockets.

STUN server for TCP flow

I am looking for a reliable STUN solution for the TCP flow. I have tried STUNT (by cornell University in the US) and XSTUNT (by a University in Taiwan). But they both seem old and useless.
What I want to do is to transfer files between two clients in two different networks via C#. Please let me know if you have any solution for either of the following:
And UDP-based Client/Server solutions for C#
Any TCP-based STUN server

Stuntman is a STUN server that supports TCP STUN.
www.stunprotocol.org
On that site, there's some links to some sample code, including C# implementations for client libraries. Most all are for UDP, but with a little work you can role your own C# code for TCP STUN by modifying one of the existing UDP code bases.
Afterwards, you will still need to implement a signaling service for exchanging address candidates (obtained directly or via STUN) and doing your own ICE-like connectivity checks.
For TCP, the easy solutions is to have both endpoints using two sockets. One socket or listening and another for connecting - but both share the same local port (ala SO_REUSEADDR socket option).
Another solution is to have each endpoint use just one socket. Both endpoints try repeatedly to do a TCP simultaneous connect. If the NAT's behave nicely, a connection can be made.
NAT traversal, especially TCP NAT Traversal, is not an exact science. There will always be cases where two endpoints can't get connected directly and will either have to fall back to UDP and/or go through a relay solution such as TURN.
Merge all the information above with the answer I wrote up last year on basic P2P/NAT traversal here.

What API can be used to send DHCP Discovery, Request, and Acknowledgement?

I have been searching for quite a while and cannot seem to find a working DHCP Client implementation example in C#. I am brand spankin' new to Network Programming, but am doing some research that requires me to write a manual DHCP client and to implement Auto-IP if there is no DHCP server.
Any code examples, or names of built-in C# classes that can help me with this would be appreciated.

You are not going to find that; the reason is “security”.
Regular net APIs allow you to handle Level-3 and up but
a DHCP client must be able to handle Level-2; i.e. for broadcasting to MAC FF:FF:FF:FF:FF:FF on DHCP DISCOVERY packets
For security reasons Microsoft today does not allow you to craft Ethernet packages at such a low level.
You cannot use raw sockets; read here why:
Limitations on Raw Sockets
http://msdn.microsoft.com/en-us/library/ms740548(v=vs.85).aspx

You can install the pccap driver on your pc and use that apI to send raw packets

TCP or UDP help with a server/client in c#?

Can anyone help, i trying to figure what i need to do, i have been given the tasks of writing a server and a client in TCP (UDP). basically multiple clients will connect to the server.. and the server sends MESSSAGES to the client.
I have no problem in creating the server and client but with tcp i am unsure whcih way to go. DOes the .net 3.5 support everything or do i need to go on the hunt for some component?
I am looking for soome good examples with c# for TCP or UDP. THis is where i am not 100% sure .. as far as i know there is UDP and TCP ... 1 is connected and 1 is not.. So which way do i go and can c# support both?? Advantages /Disadvantages?
Say if the server has to support multiple clients that i only need to open 1 port or do i need to open 2?
Also if a client crashes i need for it not to effect the SERVER hence the server can either ignore it and close connection if one is open or timeout a connection... If in fact a connection is needed again going back to tcp udp
Any ideas where i shoudl beging and choosing which protocol and amount of ports i am going to need to assign?
thanks

UDP cons:
packet size restriction means you can only send small messages (less than about 1.5k bytes).
Lack of stream makes it hard to secure UDP: hard to do an authentication scheme that works on lossy exchange, and just as hard to protect the integrity and confidentiality of individual messages (no key state to rely on).
No delivery guarantee means your target must be prepared to deal with message loss. Now is easy to argue that if the target can handle a total loss of messages (which is possible) then why bother to send them in the first place?
UDP Pros:
No need to store a system endpoint on the server for each client (ie. no socket). This is one major reason why MMO games connected to hundred of thousands of clients use UDP.
Speed: The fact that each message is routed individually means that you cannot hit a stream congestion like TCP can.
Broadcast: UDP can broadcast to all listeners on a network segment.
You shouldn't even consider UDP if you're considering TCP too. If you're considering TCP means you are thinking in terms of a stream (exactly once in order messages) and using UDP will put the burden of fragmentation, retry and acknowledgment, duplicate detection and ordering in your app. You'll be in no time reinventing TCP in your application and it took all engineers in the word 20 years to get that right (or at least as right as it is in IPv4).
If you're unfamiliar with these topics I recommend you go with the flow and use WCF, at least it gives you the advantage of switching in and out with relative ease various transports and protocols. Will be much harder to change your code base from TCP to UDP and vice versa if you made the wrong choice using raw .Net socket components.

It sounds to me like you're not clear on the distinction between TCP and UDP.
TCP is connection oriented. i.e. 2 peers will have a dedicated connection. Packet delivery and ordering is guaranteed. Typically a server will present a port, and multiple clients can connect to that port (think of a HTTP server and browsers).
UDP is connectionless. It doesn't guarantee packet delivery, nor ordering. You can implement broadcast and multicast mechanisms very easily. If you need some sort of reliability, you will have to implement this on top of UDP. Sometimes you may not care, and simply issue requests and retry on no response (SNMP does this). Because it's connectionless, you don't really worry about peers being up/down. You just have to retry if required.
So your choice of protocol is dictated by the above. e.g. does your client require a dedicated connection to the server ? Are you transmitting the same data to multiple clients ? Can you tolerate packet loss (e.g. real time price updates etc.). Perhaps it's feasible to use both TCP and UDP for different requirements within your app (e.g. TCP for registering orders, UDP for transmitting price updates/events?)
I'd consider your requirements, and familiarise yourself with the limitations and features of TCP and UDP. That should make things a little clearer.

Is there a requirement to do this at such a low level? Why not use WCF? It fully supports messaging over TCP/IP, using binary data transfer, but it's at a much higher level of abstraction than raw sockets.

Everything you need is in .Net 3.5 (and probably below). Check out the documentation and examples with the UdpClient class at MSDN for insight into how to write your client/server. A quick google found some sample code for a server and client at www.java2s.com among many other networking examples in C#. Don't be put off by the domain name.