first of all, I'm just a hobbyist, so I'm sorry if this is dumb question or if I'm being too naive. (It also means that I can't buy expensive libraries)
This is the situation: I'm building a simple voice chat application in C#.NET (something like Ventrilo or TeamSpeak but only for about 15 or 20 people, and running on 100Mbps LAN). I have working server (spawning thread for each client) and client application using UDP for connection and DirectSound for capturing and playing the sound. I can make "1 on 1" calls but I can't figure out one of the most important things:
How do i have more than two people in the conversation?
You need some centralized place to send the packets back out via a multicast, or else you need a decentralized approach where every client is connected to every other client, and each client is hosting a multicast. What you want to avoid is making the machines forward out their data to every other machine, which would result in O(n) time to send a message to each machine (and I/O is slow!).
In either scenario, you end up with the same problem: how to combine the audio streams. One simple mechanism to accomplish this is to bitwise-or the signals together before you send them back out (either out the network port, or out to your speakers), but this assumes you have access to non-compressed and reasonably-synchronized streams.
Related
I am working on a project in c# asp.net web application in which I am conducting an exam. There will be atleast 25 students taking part in the exam. There is an instructor side page where a timer periodically updates some data and it should broadcast a message to all 25 clients simultaneously.The questions to be shown to the students are depended on this message (so it should be in realtime) .Also the message should reach every client. I tried ajax polling but the application hangs when i have 10 students logged into the system . Can anyone help me with a better technology .???
*Note:- I dont want to use a timer in the client side.The message should reach every client at the same time and also should no client should miss the message. *
You can use SignalR. It's very good way to send near real time messages from server side to client side. It has both server and client side objects. On client it supports different transports that browser supports like WebSocket, Long Pooling, etc
I'd look towards something like websockets.
The first question is what exactly do you mean by "at the same time"? It's not really possible to send a message to 25 clients "at the same time". You could use UDP to broadcast the message but how would you know that all clients have received it "at the same time"?
It's a fairly tricky problem with a number of variables, such as network topology. I think you should be looking to write a custom service since ASP.NET is not really suited the situation you describe, imo.
I have a program that tells you if your computer is online or not. The way I do it is with the help of a Server that basically sends UDP packets to clients. Clients then respond back letting the server know that they are online. If a client does not respond for the next 5 seconds then I mark it as offline.
Anyways I was testing this service and from a different computer I sent thousands of udp packets to the Server. After sending so many packages the server was not working the way it was supposed to.
So I know if someone is sending me a lot of packets. The problem is how do I block those packages so that my Server can still work?
Edit Possible Solution
I think I will implement the following solution what u guys think?
I will require 2 or more Servers now. If one client finds that the server is not responding then it will then talk to the Second Server. So the attacker will also have to know that there is a second server. Depending on how secure you want to be you could have even 5 servers. I guess that if the attacker knows that there are 5 servers then I just wasted my time and money right? lol
The general solution to this is you buy extra hardware that goes in front of the computer that looks at the incoming packets.
What that extra hardware does depends on what solution you want to use, you could have that hardware distribute the requests to many servers all running the same software (this would make the hardware you added a Load Balancer). You also could have the hardware detect that a unusually large number of packets coming from a single address, the hardware could then start dropping packets from that address instead of forwarding them on to the server (this would make the hardware you added a Stateful Firewall)
There are more options beyond those two but all solutions revolve around reducing the load on the server (usually shifting the load to another piece of hardware dedicated to taking the load). You could potentially upgrade your software to be more resilient to packet floods but unless your current software is written very poorly it won't buy you too much more capacity.
I'm writing an instant messaging server in C# for learning purposes.
My question is whether I should use synchronous or asynchronous sockets to handle the IM clients. The goal is to handle as many clients as possible.
I'm not quite sure but as far as I know with async sockets the packets don't arrive in order which means when you send 2 chat messages and there is a delay/lag it's possible that the second one arrive before the first one. Is this right and if so, is there a way to solve this issue?
About sync sockets: Is synchronous sockets a good solution for many clients? Do I have to check every socket/connection in a loop if there are new packets? If so, isn't this quite slow?
Last question: Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading?
The goal is to handle as many clients as possible.
Async then. It scales a lot better.
I'm not quite sure but as far as I know with async sockets the packets don't arrive in order which means when you send 2 chat messages and there is a delay/lag it's possible that the second one arrive before the first one.
TCP guarantees that everything arrives in order.
Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading
I recommend that you use a separate connection for file transfers. Use the first connection to do a handshake (determine which port to use and specify file name etc). Then use Socket.SendFile on the new socket to transfer the file.
Everything #jgauffin said (i.e. TCP handles packet-order, async better for n(clients) > 1000).
Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading?
Your custom protocol has to be built to support this. If you write a 8MB packet to the Socket, you won't be able to write anything else using that socket until the 8MB are sent. Instead, use upload-chunks of smaller size so that other packets have the chance to go over the pipe as well.
[UPLOAD id=123 START length=8012389]
[UPLOAD id=123 PART chunk=1 length=2048 data=...]
[UPLOAD id=123 PART chunk=2 length=2048 data=...]
[MESSAGE to="foo#example.com" text="Hi"]
[UPLOAD id=123 PART chunk=3 length=2048 data=...]
// ...
[UPLOAD id=123 COMPLETE checksum=0xdeadbeef]
The difference between an async approach and a sync approach is more about the difference between non-blocking and blocking io. With both approaches, the data is delivered in the same order that it has been transmitted. However, you don't block while you wait for an async call to complete, so you can start transmitting to all of your clients, before any of the individual communications has finished writing to the socket (which is why typically it would be the approach followed by servers).
If you go down the sync route, you block until each transmission / receive operation has completed, which means you may require need to run multiple threads to handle the clients.
As far as uploading an image at the same time as sending messages, you may want to handle that down a different pipe connection between the client/server so that it doesn't cause a blockage.
I'm a Jr. Engineer hoping to seek some advice from all of the experienced people in here in regards to how to approach this.
I've been assigned a project to create a server/client application that does byte streaming through TCP. Our company deals with 2-way radios with GPS with a dispatch software and we would like to make a server/client application out of that. Currently the dispatch software can be hooked up to a central base station where a user has to be, but we want to make this software accessible from a remote location (if the base station is by a repeater miles away from where a dispatcher can be at).
User/Client -> poll location of a mic -> server -> base station -> OTA signal -> radio and back
I've been looking at Windows Communication Foundation, but what are other ways I can approach this?
I'll be primarily using C# / .NET / Visual Studio 2008
We have used UDP to send GPS updates from cars to a server that processes the updates. In applications like that (where you often have limited bandwidth) you can really tell the difference (in terms of how long it takes to get the data from the remote host to the server) between UDP and momentary TCP connections (like HTTP). A UDP packet will get to its destination in what seems like an instant, and the setup for the TCP connection is very conspicuous, often taking several seconds to complete. I like the WCF framework, but if your app is the sort of system I've been working with, I doubt you'll be happy with it (...unless it's OK to have a long interval between updates).
Lately, I've been working with persistent TCP connections (using raw Sockets), which is a good way to go if you want to make sure your packets arrive at their destination. Though the way to do that, I believe, is to leave the connection open as long as you can and incorporate code to reconnect it if it breaks.
If you just want a raw byte stream, then a Socket or the slightly more encapsulated TcpClient might be a more light weight solution.
But if you want to send complete data structures and "call functions" then WCF seems like a good choice.
With WCF you have a programming experience close to calling regular methods with real objects as parameters, but with a Socket you just send byte arrays and need to interpret the result all by your self.
We're developing a server application that uses sockets to handle client communication, obviously we want to test the server. Does anyone know of a good (open source) harness that can test the server using multiple threads on multiple client machines?
Quite frankly I would just roll your own and that's always what I do. A open source application would not be able to send packets according to your application level protocol as I'd advise to test at least authentication, some basic application level instructions, etc.
What I usually do is, write a stress tester application that spawns x amount (I usually test about 1000 clients per server) of clients and then just use a Timer (e.g. 25ms resolution) and on every timer callback, I randomly pick one of the connected clients and randomly execute either nothing, send data or disconnect the client. If I receive a disconnect notification for one of the clients, I spawn a new one to bring the total connected count back to x.
Then I let the whole thing run for a couple hours...