I am quite new with c# and app developing. How do I establish connection and send packets via UDP. I have tried to follow
https://msdn.microsoft.com/en-us/library/windows/apps/hh202864(v=vs.105).aspx
It doesn't work as it is ment for wp8
My here is not a real answer, but a workaround.
Instead of worrying about sending values via UDP socket, I'd suggest you to use a buffer/queue and implement a REST API on the server side, sending the data via HTTP requests, which is more reliable and easier to maintain...
You, of course, would send them in a async fashion, and you would still be able to juggle them up anyway you want server side...
Related
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.
My client sends messages to the my server using tcp protocol (my server has a listener).
I'm trying to send messages back from the server to the client, but I'm not sure what do I need to add to the client in order to get those messages.
I tried looking it up, but I didn't understand how to implement it.
Could you please assist?
It's the exact same process, but in reverse.
If you intend to receive messages independently (i.e. not in response to a request by the client), you need to make the client a TCP server, too. The client needs to implement exactly the same thing as the server you have now and the server needs to connect to the client.
Can't you use WCF, which supports callback contracts?
If you want a console example of a client server application using a network library see here http://www.networkcomms.net/how-to-create-a-client-server-application-in-minutes/.
If you want a WPF application example then see here http://www.networkcomms.net/creating-a-wpf-chat-client-server-application/
I have a server & a client. The client is my Android phone. The server is my PC running Windows.
I'm needing to find out the best programmable method of sending a short string to the PC and having it displayed real-time.
Please keep in mind the only languages I can program in on my server-side is VB.NET, C#, and C++ (and my experience with them is in that order).
Edit:
I don't care about security or anything. Both devices will be on a private wifi network. I can't rely on 3rd party applications though, considering the computer running the server will have very little RAM.
If it's just a simple string, and you don't care too much about security or reliability, you could go about this using java.net.Socket. Create a Socket, giving it your PCs IP address, an open port, etc. Write up an application on the PC to listen to that port, and handle the data as it would. I have no idea how you would go about doing the server-side part, as I've only really used Java, but it shouldn't be that hard if you're going with raw sockets. With the Socket on your android, create an output stream, and pass the string through that stream.
If you need a more secure, more reliable, more standard protocol of delivering a string, I'd probably go with HTTP. You might have to read up more about it, but they're better overall. Sockets aren't a whole lot simpler, though.
You can write a .NET project which communicates with sockets. Your PC could listen to a given port and your phone would access that port. This article might help you to learn more about .NET socket programming and you will be able to use C# or Visual Basic as you want.
What makes more sense?
use one socket to send and receive data to/from a embedded hardware device
use one socket to send data and separate socket to read data
Communication is not very intensive but the important point is to receive data as fast as possible. Application works under Windows XP and up.
Sockets were designed for two way communication, so most likely the developers of the embedded device didn't design their system to work off two sockets.
I have some experience working with embedded hardware and I've seen them work various ways:
Device connects to your application and starts streaming data via UDP
In this scenario I've seen up to three sockets in play. One TCP listening socket that accepts a connection from the embedded device. The embedded device then sends through some connection parameters, such as how quickly it's going to send you the data. The embedded device then starts streaming data via upd. Once you've received the data you send a message down a second upd socket to say "I got that one". The device then starts streaming the next bit of data (again via upd). This then continues ad infinitum. I've seen variations where the initial TCP connection is skipped and device just constantly stream data.
Request/Response
How many sockets you'll need here depends on who's making the initial connection, as that'll determine who needs the listening socket. Since you're making the initial connection, I'll use that. This is the more connection oriented scenario. Here you make a connection to the device and request some data, the device then sends you the response to that data. In this scenarioyou can only use one socket. As the device will respond to each request on the socket it was received.
So to answer you question "What makes more sense?", it completely depends on the design of your embedded device. If it's responding on the same socket as you're requesting, the answer is simple as only one socket is possible. Streaming devices via upd should give better performance with two sockets, but again only if your device supports it.
As for the second part of your question, "to receive data as fast as possible.", that's easy go asynchronous. Here are some excellent blogs on asynchronous socket programming:
.NET Sockets - Two Way - Single Client (C# Source Code - Included)
.NET Sockets in Two Directions with Multiple Client Support (C# Source Code Included)
If you're using a custom/third party protocol to communicate with the device you can't go wrong having a read through these either:
How to Transfer Fixed Sized Data With Async Sockets
Part 2: How to Transfer Variable Length Messages With Async Sockets
Im no expert but is there any downside to just using one socket?
It can already send and receive and my guess is that you end up getting more overhead if you have one socket for reading and one for sending...
Tooday I use ServiceHost for self hosting WCF cervices.
I want to host near to my WCF services my own TCP programm for direct sockets operations (like lien to some sort of broadcasting TCP stream)
I need control over URL namespaces (so I would be able to let my clients to send TCP streams directly into my service using some nice URLs like example.com:port/myserver/stream?id=1 or example.com:port/myserver/stream?id=anything and so that I will not be bothered with Idea of 1 client for 1 socket at one time moment, I realy want to keep my WCF services on the same port as my own server or what it is so to be able to call www.example.com:port/myWCF/stream?id=222... and I want it to work on Any port - not only 80)
Can any body please help me with this?
I am using just WCF now. And I do not enjoy how it works. That is one of many resons why I want to start migration to clear TCP=)
I can not use net-tcp binding or any sort of other cool WS-* binding (tooday I use the simpliest one so that my clients like Flash, AJAX, etc connect to me with ease).
I needed Fast and easy in implemrnting connection protocol like one I created fore use with Sockets for real time hi ammount of data transfering.
So.. Any Ideas? Please - I need help.
Well if you're going to drop down to pure sockets, you could as well make your service act as proxy. Make WCF Services listen on some other port, and your app on the desired port. When you receive request in your app, manually parse header and check weather it is intended for your service or WCF Service. If it's intended for WCF service, open a TCP connection to WCF service and pass the received data to it, and then simply pass back WCF's answer to the client..
On the other hand you could speed up WCF quite a lot by writing your own custom binding. Lots of time WCF looses on serialization that is done using reflection (which is slow), going around this would improve your speed considerably.
If your problem with WCF is performance then you should try the binary net TCP binding to eliminate XML serialization to improve performance.
Some high traffic applications, like realtime games, use UDP for the majority of communication since it cuts through the protocol. With TCP you get ordering and reliability built in, but this comes at the cost of performance because it will implicitly delay packets to wait for out of order packets so that it can hand them to the application in the correct order, or wait for lost packets to be resent. Instead you can use UDP and implement your own scheme for verification of data that is less stringent than TCP.
There are UDP options available for WCF, or you could implement your own. WCF is nothing more than a message pump, and you can replace different steps with whatever you want.
Not sure if this will help you or not, but try turning on your Net TCP Sharing Service.