Can two applications on the same machine bind to the same port and IP address? Taking it a step further, can one app listen to requests coming from a certain IP and the other to another remote IP? 
I know I can have one application that starts off two threads (or forks) to have similar behavior, but can two applications that have nothing in common do the same?

Can two applications listen to the same port?

Since TCP guarantees packet delivery and thus can be considered &quot;reliable&quot;, whereas UDP doesn&#39;t guarantee anything and packets can be lost. What would be the advantage of transmitting data using UDP in an application rather than over a TCP stream? In what kind of situations would UDP be the better choice, and why?

I&#39;m assuming that UDP is faster since it doesn&#39;t have the overhead of creating and maintaining a stream, but wouldn&#39;t that be irrelevant if some data never reaches its destination?

When is it appropriate to use UDP instead of TCP?

I&#39;ve read a number of articles about UDP packet sizes but have been unable to come to a conclusion on whats correct.

A number of services restrict the largest UDP packet to 512 bytes (like dns)

Given the minimum [MTU][1] on the internet is 576 , and the size of the IPv4 header is 20 bytes, and the UDP header 8 bytes.   This leaves 548 bytes available for user data 

Would I be able to use packets up to the size of 548 without packet fragmentation?  Or is there something the creators of DNS knew about, and that why they restricted it to 512 bytes.

Could I even go higher than 548 bytes safely?


  [1]: http://en.wikipedia.org/wiki/Maximum_transmission_unit &quot;Maximum Transmission Unit&quot;

What is the largest Safe UDP Packet Size on the Internet

For general protocol message exchange, which can tolerate some packet loss.  How much more efficient is UDP over TCP?

UDP vs TCP, how much faster is it?

Sorry about the length, it&#39;s kinda necessary.

**Introduction**


I&#39;m developing a remote desktop software (just for fun) in C# 4.0 for Windows Vista/7. I&#39;ve gotten through basic obstacles: I have a robust UDP messaging system, relatively clean program design, I&#39;ve got a mirror driver (the free DFMirage mirror driver from DemoForge) up and running, and I&#39;ve implemented NAT traversal for all NAT types except Symmetric NATs (present in corporate firewall situations).

Regarding screen transfer/sharing, thanks to the mirror driver, I&#39;m automatically notified of changed screen regions and I can simply marshal the mirror driver&#39;s ever-changing screen bitmap to my own bitmap. Then I compress the screen region as a PNG and send it off from the server to my client. Things are looking pretty good, but it&#39;s not fast enough. It&#39;s just as slow as VNC (btw, I don&#39;t use the VNC protocol, just a custom amateur protocol).

From the slowest remote desktop software to the fastest, the list usually begins at all VNC-like implementations, then climbs up to Microsoft Windows Remote Desktop...and then...TeamViewer. Not quite sure about CrossLoop, LogMeIn - I haven&#39;t used them, but TeamViewer is *insanely* fast. It&#39;s quite literally live. I ran a `tree` command on Command Prompt and it updated with 20 ms delay. I can browse the web just a few milliseconds slower than on my laptop. Scrolling code vertically in Visual Studio has 50 ms lag time. Think about how robust TeamViewer&#39;s screen-transfer solution must be to accomplish all this.

VNCs use poll-based hooks for detecting screen change and brute force screen capturing/comparing at their worst. At their best, they use a mirror driver like DFMirage. I&#39;m at this level. And they use something called the RFB protocol.

Microsoft Windows Remote Desktop apparently goes one step higher than VNC. I heard, from somewhere on StackOverflow, that Windows Remote Desktop doesn&#39;t send screen bitmaps, but actual drawing commands. That&#39;s quite brilliant, because it can just send simple text (draw this rectangle at this coordinate and color it with this gradient)! Remote Desktop really is pretty fast - and it&#39;s the standard way of working from home. And it uses something called the RDP protocol.

Now TeamViewer is a complete mystery to me. Apparently, they released their source code for Version 2 (TeamViewer is Version 7 as of February 2012). People have read it and said that Version 2 is useless - that it&#39;s just a few improvements over VNC with automatic NAT traversal. 

But Version 7...it&#39;s ridiculously fast now. I mean, it&#39;s actually faster than Windows Remote Desktop. I&#39;ve streamed DirectX 3D games with TeamViewer (at 1 fps, but Windows Remote Desktop doesn&#39;t even allow DirectX to run).

By the way, TeamViewer does all this *without* a mirror driver. There is an option to install one, and it gets just a bit faster.

**The Question**

**My question is, how is TeamViewer so fast?** It must not be possible. If you&#39;ve got 1920 by 1080 resolution at even 24 bit depth (16 bit depth would be noticeably ugly), thats still 6,220,800 bytes raw. Even using libjpeg-turbo (one of the fastest JPG compression libraries used by large corporations), compressing it down to 30KB (let&#39;s be extremely generous), would take time to route through TeamViewer&#39;s servers (TeamViewer bypasses corporate Symmetric NATs by simply proxying traffic through their servers). And that libjpeg-turbo compression would take time to compress. High-quality JPG compression takes 175 milliseconds for a full 1920 by 1080 screenshot for me. And that number goes up if the host&#39;s computer runs an Atom processor. I simply don&#39;t understand how TeamViewer has optimized their screen transfer so well. Again, small-size images might be highly compressed, but take at least tens of milliseconds to compress. Large-size images take no time to compress, but take a long time to get through. Somehow, TeamViewer completes this entire process to get roughly 20-25 frames per second. I&#39;ve used a network monitor, and TeamViewer is still lagless at speeds of 500 Kbps and 1 Mbps (VNC software lag for a few seconds at that transfer rate). During my `tree` Command Prompt test, TeamViewer was receiving inbound data at a rate of 1 Mbps and still running 5-6 fps. VNC and remote desktop don&#39;t do that. So, how?

The answers will be somewhat complicated and intricate, so *please don&#39;t post your $0.02 if you&#39;re only going to say it&#39;s because they use UDP instead of TCP* (would you believe they actually do use TCP just as successfully though).

I&#39;m hoping there&#39;s a TeamViewer developer somewhere here on StackOverflow.

**Potential Answers**

Will update this once people reply.

1. My thoughts are, first of all, that TeamViewer has very fine network control. For example, they split large packets to just under the MTU size and never waste a trip. They probably have all sorts of fancy hooks to detect screen changes along with extremely fast XOR image comparisons.

How is TeamViewer so fast?

Conventional IPv4 dotted quad notation separates the address from the port with a colon, as in this example of a webserver on the loopback interface:

    127.0.0.1:80

but with IPv6 notation the address itself can contain colons. For example, this is the short form of the loopback address:

    ::1

How are ports (or their functional equivalent) expressed in a textual representation of an IPv6 address/port endpoint? 

How do ports work with IPv6?

What is the difference between TCP and UDP? 

I know that TCP is used in the case of non-time critical applications, and UDP is used for games or applications that require fast transmission of data. I know that TCP is used for HTTP, HTTPs, FTP, SMTP, and Telnet. I know that UDP is used for DNS and DHCP.

But why? What characteristics of TCP and UDP make it useful for their respective use cases? 

Difference between TCP and UDP?

How do I forward a UDP port from my Docker container to the host machine?

How do I publish a UDP Port on Docker?

I want to send only one short value in a UDP packet, but running the command

    echo -n &quot;hello&quot; | nc -4u localhost 8000

I can see that the server is getting the _hello_ stuff but I have to press &lt;kbd&gt;Ctrl&lt;/kbd&gt;+&lt;kbd&gt;c&lt;/kbd&gt; to quit the netcat command. 

How can I make it quit after sending _hello_?

---

Sorry, for the noise, I re-read the man page and found the `-q` option.

     echo -n &quot;hello&quot; | nc -4u -q1 localhost 8000

works (it quits after 1 second).

For some reason it does not work with `-q0`.

How to send only one UDP packet with netcat?

First of all, is there any problem with using both UDP and TCP on the same server?

Secondly, can I use the same port number?

Can TCP and UDP sockets use the same port?

This might be a silly question:

- Does HTTP ever use the User Datagram Protocol? 

**For example:** 

&gt; If one is streaming MP3 or video  using HTTP,  does it internally use UDP for transport?

Does HTTP use UDP?

I just came home from my exam in network-programming, and one of the question they asked us was **&quot;If you are going to stream video, would you use TCP or UDP? Give an explanation for both stored video and live video-streams&quot;**. To this question they simply expected a short answer of TCP for stored video and UDP for live video, but I thought about this on my way home, and is it necessarily better to use UDP for streaming live video? I mean, if you have the bandwidth for it, and say you are streaming a soccer match, or concert for that matter, do you really need to use UDP?

Lets say that while you are streaming this concert or whatever using TCP you start losing packets (something bad happened in some network between you and the sender), and for a whole minute you don&#39;t get any packets. The video-stream will pause, and after the minute is gone packets start to get through again (IP found a new route for you). What would then happen is that TCP would retransmit the minute you lost and continue sending you the live stream. As an assumption the bandwidth is higher than the bit-rate on the stream, and the ping is not too high, so in a short amount of time, the one minute you lost will act as a buffer for the stream for you, that way, if packet-loss happens again, you won&#39;t notice.

Now, I can think of some appliances where this wouldn&#39;t be a good idea, like for instance video-conferences, where you **need** to always be at the end of the stream, because delay during a video-chat is just horrible, but during a soccer-match, or a concert what does it matter if you are a single minute behind the stream? Plus, you are guaranteed that you get all the data and it would be better to save for later viewing when it&#39;s coming in without any errors.

So this brings me to my question. Are there any drawbacks that I don&#39;t know of about using TCP for live-streaming? Or should it really be, that if you have the bandwidth for it you should go for TCP given that it is &quot;nicer&quot; to the network (flow-control)?

TCP vs UDP on video stream

If you have a situation where a TCP connection is potentially too slow and a UDP &#39;connection&#39; is potentially too unreliable what do you use? There are various standard reliable UDP protocols out there, what experiences do you have with them?

Please discuss one protocol per reply and if someone else has already mentioned the one you use then consider voting them up and using a comment to elaborate if required.

**I&#39;m interested in the various options here, of which TCP is at one end of the scale and UDP is at the other. Various reliable UDP options are available and each brings some elements of TCP to UDP.**

I know that often TCP is the correct choice but having a list of the alternatives is often useful in helping one come to that conclusion. Things like Enet, RUDP, etc that are built on UDP have various pros and cons, have you used them, what are your experiences?

For the avoidance of doubt there is no more information, this is a hypothetical question and one that I hoped would elicit a list of responses that detailed the various options and alternatives available to someone who needs to make a decision.

What do you use when you need reliable UDP?

This sounds like a very basic question, but I need a confirmation

 1. Does WebRTC use TCP or UDP as its peer-to-peer transport? How do I
    know ?
 2. I read that there are reliability mode and DTLS agreement, how does
    they affect?
 3. Is this transport the same for both Media and DataChannel?
 4. How do I switch between TCP and UDP?

I ask this because I know that browsers have a limit on the number of parallel connections  (I think they talk about TCP), and maybe UDP connection is not limited.

Does WebRTC use TCP or UDP?

I&#39;m writing a JavaScript Application that has to receive a huge amount of data from other users. It is not important if some of this data gets lost. Is there some way of using JavaScript WebSockets with UDP instead of TCP?

JavaScript WebSockets with UDP?

I know the difference between the two on a technical level.

But in real life, can anyone provide examples (the more the better) of applications (uses) of TCP and UDP to demonstrate the difference?

What are examples of TCP and UDP in real life?

I am using multicast UDP between hosts that have multiple network interfaces.
I am using boost::asio, and am confused by the 2 operations receivers have to make: bind, then join-group.

Why do you need to specify the local address of an interface, during bind, when you do that with every multicast group that you join?

The sister-question regards the multicast port: Since during sending, you send to a multicast address &amp; port, why, during subscription to a multicast group, you only specify the address, not the port - the port being specified in the confusing call to bind.


Note: the &quot;join-group&quot; is a wrapper over `setsockopt(IP_ADD_MEMBERSHIP)`, which as documented, may be called multiple times on the same socket to subscribe to different groups (over different networks?). It would therefore make perfect sense to ditch the bind call and specify the port every time I subscribe to a group.

From what I see, always binding to &quot;0.0.0.0&quot; and specifying the interface address when joining the group, works very well. Confused.

What does it mean to bind a multicast (UDP) socket?

How should I choose an IPv4 multicast address for my application&#39;s use? I may need more than one (a whole range perhaps ultimately) but just want to avoid conflicts with other applications.

* Packets will be entirely contained within an administrative domain, probably a LAN
* If several independent instances of my application are in use on the same network, they could each use their own multicast address - but if they don&#39;t, they will be able to coexist anyway, they&#39;ll just have a small amount of overhead ignoring each others&#39; packets.
* My packets already contain a &quot;magic number&quot; to avoid problems
* I will be checking the originator address (which I know can be spoofed of course), TTL and other things to try to prevent unexpected packets mucking things up.

Ideas please :)

Currently I&#39;ve just allocated an arbitrary one from the &quot;local use&quot; space, 239.255.42.99

How do I choose a multicast address for my application&#39;s use?

HTML5 websockets currently use a form of TCP communication. However, for real-time games, TCP just won&#39;t cut it (and is great reason to use some other platform, like native). As I probably need UDP to continue a project, I&#39;d like to know if the specs for HTML6 or whatever will support UDP?


Also, are there any reliable benchmarks for WebSockets that would compare the WS protocol to a  low-level, direct socket protocol?

WebSockets, UDP, and benchmarks

This question is &lt;b&gt;NOT&lt;/b&gt; for the difference between STREAM type and DATAGRAM type INTERNET sockets. I know that STREAM sockets use TCP, Datagram sockets use UDP and all the TCP,UDP stuff, packets arriving in order, ACK, NACK etc.
I understand the importance of these over internet.

Q1) When I create a UNIX domain socket which is a local socket, how would it matter if the socket is STREAM socket or DATAGRAM socket. This type of socket would write the data to the socket file, would the protocol matter in this case since I am not transmitting data over a network? Is there any chance of data loss in this case if I use UNIX-based DATAGRAM sockets?
&lt;br&gt;&lt;br&gt;
Q2) Does UNIX DATAGRAM sockets provide better performance than UNIX STREAM sockets?
&lt;br&gt;&lt;br&gt;
Q3) How to decide for a STREAM/DATAGRAM UNIX based socket in my application?

&lt;BR&gt;
Thanks

Difference between UNIX domain STREAM and DATAGRAM sockets?

In the documentation of hardware that allows us to control it via UDP/IP,
I found the following fragment:

&gt; In this communication protocol, DWORD is a 4 bytes data, WORD is a 2 bytes data,
&gt; BYTE is a single byte data. The storage format is little endian, namely 4 bytes (32bits) data is stored as: d7-d0, d15-d8, d23-d16, d31-d24; double bytes (16bits) data is stored as: d7-d0 , d15-d8.

I am wondering how this translates to C#?
Do I have to convert stuff before sending it over?
For example, if I want to send over a 32 bit integer, or a 4 character string?





C# little endian or big endian?

What exactly is a TCP connection?
I understand there isn&#39;t a physical connection from the client to server. Is this connection just the client&#39;s socket being linked with the new socket created by the server after the three-way-handshake? 
Thereafter once the &quot;connection&quot; is set up, the sockets on either ends of the connection then know where to send their packets.

How does this differ from the way UDP functions other than the initial handshake with TCP?
Is it that each server socket only has one client that sends packets to that particular socket?

What are some possible advantages of having a dedicated connection between hosts? My understanding of TCP and UDP is still very basic, so broad generalizations should suffice.

TCP vs UDP - What is a TCP connection?

I need to know what the largest UDP packet I can send to another computer is without fragmentation.

This size is commonly known as the MTU (Maximum Transmission Unit). Supposedly, between 2 computers, will be many routers and modems that may have different MTUs. 

I read that the TCP implementation in windows automatically finds the maximum MTU in a path.

I was also experimenting, and I found out that the maximum MTU from my computer to a server was 57712 bytes+header. Anything above that was discarded. My computer is on a LAN, isn&#39;t the MTU supposed to be around 1500 bytes?

How to find the largest UDP packet I can send without fragmenting?

I have a java app on linux which opens UDP socket and waits for messages.

After couple of hours under heavy load, there is a packet loss, i.e. the packets are received by kernel but not by my app (we see the lost packets in sniffer, we see UDP packets lost in netstat, we don&#39;t see those packets in our app logs).

We tried enlarging socket buffers but this didnt help - we started losing packets later then before, but that&#39;s it.

For debugging, I want to know how full the OS udp buffer is, at any given moment. Googled, but didn&#39;t find anything. Can you help me?

P.S. Guys, I&#39;m aware that UDP is unreliable. However - my computer receives all UDP messages, while my app is unable to consume some of them. I want to optimize my app to the max, that&#39;s the reason for the question. Thanks. 

How to monitor Linux UDP buffer available space?

I have a TCP server that listens for an incoming client, then sends it one packet of data every second. I was wondering, does the SYN/ACK packet only get sent on initial connection, so it looks like this:

    &lt;client connect&gt;
    SYN
    ACK
    DATA
    DATA
    DATA
    &lt;client disconnect&gt;

Or does it get sent with every packet, like this?
    
    &lt;client connect&gt;
    SYN
    ACK
    DATA

    SYN
    ACK
    DATA

    SYN
    ACK
    DATA
    &lt;client disconnect&gt;

Also, if it&#39;s the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?

Does TCP send a SYN/ACK on every packet or only on the first connection?

OK this is one I&#39;ve been trying to figure out for a few days now. We have an application on Windows Phone 7 where phones join a multicast group and then send and receive messages to the group to talk to each other. Note - this is phone to phone communication.

Now I&#39;m trying to port this application to Windows Phone 8 - using the &#39;Convert to Phone 8&#39; feature in Visual Studio 2012 - so far so good. Until I try to test the phone to phone communication. The handsets seem to join the group fine, and they send the datagrams OK. They even receive the messages that they send to the group - however, no handset ever receives a message from another handset.

Here is the sample code behind to my page:

    // Constructor
    public MainPage()
    {
        InitializeComponent();
    }

    // The address of the multicast group to join.
    // Must be in the range from 224.0.0.0 to 239.255.255.255
    private const string GROUP_ADDRESS = &quot;224.0.1.1&quot;;

    // The port over which to communicate to the multicast group
    private const int GROUP_PORT = 55562;
 
    // A client receiver for multicast traffic from any source
    UdpAnySourceMulticastClient _client = null;

    // Buffer for incoming data
    private byte[] _receiveBuffer;

    // Maximum size of a message in this communication
    private const int MAX_MESSAGE_SIZE = 512;

    private void PhoneApplicationPage_Loaded(object sender, RoutedEventArgs e)
    {
        _client = new UdpAnySourceMulticastClient(IPAddress.Parse(GROUP_ADDRESS), GROUP_PORT);
        _receiveBuffer = new byte[MAX_MESSAGE_SIZE];

        _client.BeginJoinGroup(
            result =&gt;
            {
                _client.EndJoinGroup(result);
                _client.MulticastLoopback = true;
                Receive();
            }, null);
    }

    private void SendRequest(string s)
    {
        if (string.IsNullOrWhiteSpace(s)) return;

        byte[] requestData = Encoding.UTF8.GetBytes(s);

        _client.BeginSendToGroup(requestData, 0, requestData.Length,
            result =&gt;
            {
                _client.EndSendToGroup(result);
                Receive();
            }, null);
    }

    private void Receive()
    {
        Array.Clear(_receiveBuffer, 0, _receiveBuffer.Length);
        _client.BeginReceiveFromGroup(_receiveBuffer, 0, _receiveBuffer.Length,
            result =&gt;
            {
                IPEndPoint source;

                _client.EndReceiveFromGroup(result, out source);

                string dataReceived = Encoding.UTF8.GetString(_receiveBuffer, 0, _receiveBuffer.Length);

                string message = String.Format(&quot;[{0}]: {1}&quot;, source.Address.ToString(), dataReceived);
                Log(message, false);

                Receive();
            }, null);
    }
    
    private void Log(string message, bool isOutgoing)
    {
        if (string.IsNullOrWhiteSpace(message.Trim(&#39;\0&#39;)))
        {
            return;
        }

        // Always make sure to do this on the UI thread.
        Deployment.Current.Dispatcher.BeginInvoke(
        () =&gt;
        {
            string direction = (isOutgoing) ? &quot;&gt;&gt; &quot; : &quot;&lt;&lt; &quot;;
            string timestamp = DateTime.Now.ToString(&quot;HH:mm:ss&quot;);
            message = timestamp + direction + message;
            lbLog.Items.Add(message);

            // Make sure that the item we added is visible to the user.
            lbLog.ScrollIntoView(message);
        });

    }
    
    private void btnSend_Click(object sender, RoutedEventArgs e)
    {
        // Don&#39;t send empty messages.
        if (!String.IsNullOrWhiteSpace(txtInput.Text))
        {
            //Send(txtInput.Text);
            SendRequest(txtInput.Text);
        }
    }

    private void btnStart_Click(object sender, RoutedEventArgs e)
    {
        SendRequest(&quot;start now&quot;);
    }

In order to simply test out the UDP stack, I downloaded the sample from MSDN found [here](http://code.msdn.microsoft.com/wpapps/Multicast-Sockets-Sample-51190c11) and I tested this on a pair of Windows Phone 7 devices and it works as expected. Then I converted to Windows Phone 8 and deployed to my handsets, again the devices seem to initiate their connection, and the user can enter their name. However, again the devices can&#39;t see or communicate with other devices.

Finally I implemented a simple communication test using the new DatagramSocket implementation, and again I see successful initiation, but no inter-device communication.

This is the same code behind page using the datagram socket implementation:

    // Constructor
    public MainPage()
    {
        InitializeComponent();
    }

    // The address of the multicast group to join.
    // Must be in the range from 224.0.0.0 to 239.255.255.255
    private const string GROUP_ADDRESS = &quot;224.0.1.1&quot;;

    // The port over which to communicate to the multicast group
    private const int GROUP_PORT = 55562;

    private DatagramSocket socket = null;

    private void Log(string message, bool isOutgoing)
    {
        if (string.IsNullOrWhiteSpace(message.Trim(&#39;\0&#39;)))
            return;

        // Always make sure to do this on the UI thread.
        Deployment.Current.Dispatcher.BeginInvoke(
        () =&gt;
        {
            string direction = (isOutgoing) ? &quot;&gt;&gt; &quot; : &quot;&lt;&lt; &quot;;
            string timestamp = DateTime.Now.ToString(&quot;HH:mm:ss&quot;);
            message = timestamp + direction + message;
            lbLog.Items.Add(message);

            // Make sure that the item we added is visible to the user.
            lbLog.ScrollIntoView(message);
        });
    }
    
    private void btnSend_Click(object sender, RoutedEventArgs e)
    {
        // Don&#39;t send empty messages.
        if (!String.IsNullOrWhiteSpace(txtInput.Text))
        {
            //Send(txtInput.Text);
            SendSocketRequest(txtInput.Text);
        }
    }

    private void PhoneApplicationPage_Loaded(object sender, RoutedEventArgs e)
    {
        socket = new DatagramSocket();
        socket.MessageReceived += socket_MessageReceived;

        try
        {
            // Connect to the server (in our case the listener we created in previous step).
            await socket.BindServiceNameAsync(GROUP_PORT.ToString());
            socket.JoinMulticastGroup(new Windows.Networking.HostName(GROUP_ADDRESS));
            System.Diagnostics.Debug.WriteLine(socket.ToString());
        }
        catch (Exception exception)
        {
            throw;
        }
    }

    private async void SendSocketRequest(string message)
    {
        // Create a DataWriter if we did not create one yet. Otherwise use one that is already cached.
        //DataWriter writer;
        var stream = await socket.GetOutputStreamAsync(new Windows.Networking.HostName(GROUP_ADDRESS), GROUP_PORT.ToString());
        //writer = new DataWriter(socket.OutputStream);
        DataWriter writer = new DataWriter(stream);

        // Write first the length of the string as UINT32 value followed up by the string. Writing data to the writer will just store data in memory.
       // stream.WriteAsync(
        writer.WriteString(message);

        // Write the locally buffered data to the network.
        try
        {
            await writer.StoreAsync();
            Log(message, true);
            System.Diagnostics.Debug.WriteLine(socket.ToString());
        }
        catch (Exception exception)
        {
            throw;
        }
        finally
        {
            writer.Dispose();
        }
    }

    void socket_MessageReceived(DatagramSocket sender, DatagramSocketMessageReceivedEventArgs args)
    {
        try
        {
            uint stringLength = args.GetDataReader().UnconsumedBufferLength;
            string msg = args.GetDataReader().ReadString(stringLength);

            Log(msg, false);
        }
        catch (Exception exception)
        {
            throw;
        }
    }

Last night I took the handsets home to test them on my home wireless network, low and behold I get successful device communication. 

So to recap - my legacy Windows Phone 7 code runs fine on my work network. The port to Windows Phone 8 (no actual code change) does not send inter-device communication. This code does work on my home network. The code runs with the debugger attached and there are no signs of errors or exceptions anywhere during execution.

The handsets I&#39;m using are: 

Windows Phone 7 - Nokia Lumia 900 (* 2), Nokia Lumia 800 (* 3)
Windows Phone 8 - Nokia Lumia 920 (* 1), Nokia Limia 820 (* 2)

These are all running the latest OS, and are in developer mode.
Development environment is Windows 8 Enterprise running Visual Studio 2012 Professional

I cant tell you much about the work wireless network - other than the Phone 7 devices have no trouble. 

As for the home wireless network i used, that&#39;s just a basic BT Broadband router with none of the &#39;out the box&#39; settings altered.

Clearly there is an issue with the way that the two network are configured, but there is also very clearly an issue with the way Windows Phone 8 implements UDP messages.

Any input would be appreciated as this is driving me mad right now.

UDP multicast group on Windows Phone 8

For some reason I am having a hard time sending and receiving data from the same socket. Anyways here is my client code:


    var client = new UdpClient();
    IPEndPoint ep = new IPEndPoint(IPAddress.Parse(&quot;127.0.0.1&quot;), 11000); // endpoint where server is listening (testing localy)
    client.Connect(ep); 

    // send data
    client.Send(new byte[] { 1, 2, 3, 4, 5 }, 5);

    // then receive data
    var receivedData = client.Receive(ref ep);  // Exception: An existing connection was forcibly closed by the remote host

**Basically I want to create a protocol where I send a udp packet and then I expect a response. Just like the HTTP protocol for every request there is a response.** This code works if the server is on a different computer. There might be the case where the server and client are on the same computer though.

Here is the server:

    UdpClient udpServer = new UdpClient(UDP_LISTEN_PORT);
            
    while (true)
    {
        var groupEP = new IPEndPoint(IPAddress.Any, 11000); // listen on any port
        var data = udpServer.Receive(ref groupEP);
        udpServer.Send(new byte[] { 1 }, 1); // if data is received reply letting the client know that we got his data          
    }


-----------------------------------

Edit 
---

the reason why I cannot use tcp is because sometimes the client is behind a NAT (router) and it is simpler to do UDP hole punching than TCP.



-------
Solution:
----

thanks to markmnl answer here is my code:

Server:

    UdpClient udpServer = new UdpClient(11000);

    while (true)
    {
        var remoteEP = new IPEndPoint(IPAddress.Any, 11000); 
        var data = udpServer.Receive(ref remoteEP); // listen on port 11000
        Console.Write(&quot;receive data from &quot; + remoteEP.ToString());
        udpServer.Send(new byte[] { 1 }, 1, remoteEP); // reply back
    }


Client code:

    var client = new UdpClient();
    IPEndPoint ep = new IPEndPoint(IPAddress.Parse(&quot;127.0.0.1&quot;), 11000); // endpoint where server is listening
    client.Connect(ep);

    // send data
    client.Send(new byte[] { 1, 2, 3, 4, 5 }, 5);

    // then receive data
    var receivedData = client.Receive(ref ep);

    Console.Write(&quot;receive data from &quot; + ep.ToString());

    Console.Read();



Simple UDP example to send and receive data from same socket

This morning, there were big problems at work because an SNMP trap didn&#39;t &quot;go through&quot; because SNMP is run over UDP. I remember from the networking class in college that UDP isn&#39;t guaranteed delivery like TCP/IP. And Wikipedia says that SNMP can be run over TCP/IP, but UDP is more common.

I get that some of the advantages of UDP over TCP/IP are speed, broadcasting, and multicasting. But it seems to me that guaranteed delivery is more important for network monitoring than broadcasting ability. Particularly when there are serious high-security needs. One of my coworkers told me that UDP packets are the first to be dropped when traffic gets heavy. That is yet another reason to prefer TCP/IP over UDP for network monitoring (IMO).

So why does SNMP use UDP? I can&#39;t figure it out and can&#39;t find a good reason on Google either.



Why is SNMP usually run over UDP and not TCP/IP?

When, exactly, does the BSD socket `send()` function return to the caller?

In _non-blocking mode_, it should return immediately, correct?

As for _blocking_ mode, the [man page](http://manpages.ubuntu.com/manpages/lucid/man2/send.2.html) says:

&gt;When  the  message  does  not  fit  into the send buffer of the socket, **send()** normally blocks, unless the  socket  has  been  placed  in  non-blocking  I/O  mode.

Questions:

1. Does this mean that the `send()` call will always return immediately if there is room in the kernel send buffer?
2. Is the behavior and performance of the `send()` call identical for TCP and UDP? If not, why not?


All Udp Solutions on Gang of Coders

Total of 29 Udp Solutions