I've been trying to find an answer to this question and not sure i possible.
The scenario:
My friend and I want to host a live stock trading alert broadcast. I have Icecast setup successfully on a linux server and am able to broadcast my voice using the BUTT encoder/client. This all works fine. But is there anyway to get my friend in a different location broadcasting on the same mountpoint/stream? I've tried starting BUTT as a second client on the same mountpoint, and it simply won't connect. I we set up a different mounpoint/stream, the end user (with a web player) can only listen to one stream at a time by default.
So is there anyway to mix the streams? Share the stream with two sources?
My only thought at this point is to have two web players on the web page, have them hidden and auto start them at the same time when the user gets to the page.
Thanks,
Max
It is not possible, Icecast is not intended for this usecase, so you might want to use something like Mumble to talk together and stream the Mumble audio to Icecast, instead of having both of you streaming to Icecast.
Related
I am trying to loop audio from my Icecast server 24/7.
I have seen examples where people talk about storing their audio files on the EC2 instance or in an S3 bucket.
Do I also need a source client running on my EC2 Instance to be able to stream audio to the server? Or is there a way to play static files from Icecast?
Icecast and SHOUTcast servers work by passing a live audio stream from a source on to the users. You need something to produce a single audio stream in realtime from those source files.
The flow looks something like this:
Basically, you'll need to do everything you would in a normal radio studio, but automated. You'll stream the files from your bucket, play them to a raw audio stream, send that stream to your encoder to be compressed with the codec, and then sent to your streaming servers for distribution.
You can't simply push your audio files as-is to the Icecast server, for a few reasons:
Stream must be realtimeThe server doesn't really know or care about the timing of the stream. It takes the data its given and sends that off to the client. Therefore, if you push data faster than realtime, the server will attempt to deliver it to the client at this faster rate. Some clients will attempt to buffer this fast stream, but most will put backpressure on the stream, causing the TCP window to close, causing the client to eventually get far enough behind that the server drops the connection.
Consistent format is requiredChances are, your source files have varying sample rate, channel count, and even codec. Most clients are unable to take a change in sample rate or channel count mid-stream. I don't know of any client that supports a codec change mid-stream. (Theoretically possible with Ogg and Matroska/WebM, but yeah... not worth messing with.)
Stream should be free of ID3 tags and other file format cruftIf you simply PUT your files directly to your Icecast server, the output stream will contain more than just the audio data. At a minimum, you'd want to remove all that. Depending on your container format, you'll need to deal with timestamps as well.
Solutions
There are a handful of ways to solve this:
Radio automation softwareMany folks simply run something like RadioDJ on cloud-based servers. If you already have a radio station that uses automation, this might be a good solution. It can be expensive though, and not as flexible. You could even go as low as VLC or something for playout, but then you wouldn't have music transitions and what not.
Custom playout script (recommended)I use a browser engine, such as Chromium, and script my channels with normal JavaScript. From there, I take the output stream and pass it off to FFmpeg to encode and send to the streaming servers. This works really well, as I can do all my work in a language everybody knows, and I have easy access to data on cloud-hosted services. I can use the Web Audio API to mix and blend audio based on what's happening in realtime. As an alternative, there is Liquidsoap, but I do not recommend it these days as its language is difficult to deal with and it is not as flexible as a browser engine.
I am developing a multiplayer game (client-server model) and I am stuck when it comes to scaling its servers.
I understand that most games never even reach 10 000+ players, and I don't think mine will either.
Though if I would be very lucky to get that I want to develop the servers so they cannot become a huge obsticle later.
I have searched a lot for a solution to my problem on the internet, checking GDC talks about it and checking other posts on this website, but none of them seems to solve my specific problem.
My current setup is below and all servers are written in C++ using ENet as my network library.
Game server
This server handles the actual gameplay of the game and requires quite a lot of CPU and packages being sent between the server and its connected clients.
But this dedicated server is hosted by the players themselves, so I don't have to think about scaling it at all.
Lobby server
This server handles the server list, containing all servers currently up.
All game servers are sending a UDP package to this server every 5 seconds to say they are still alive.
This is so the lobby server can keep an updated list of all servers currently online.
All clients are sending a UDP package to this server when they want to fetch all servers (which is only in the server
list screen), and the lobby server sends back a list of all servers.
This does not happen that often and the lobby server is limited to send 4 servers per second to a client (and not a huge package containing all servers).
Login server
This server handles creating accounts, lost password, logins, friends and their current game status,
private messages to other logged in players and player profiles that specifies what in-game items they have.
All clients are sending a UDP package to this server every 5 seconds to say they are still alive, while also
sending what game they are currently in. The server then sends back their friend lists online/offline/in-game statuses.
This is so their friends can keep an updated list of which friend is online/offline/in-game.
It sends messages only with player actions otherwise, like creating an account, logging in, changing/resetting password,
adding/removing/ignoring a friend, private messages to friends, etc.
My questions
What I am worried about is that my lobby and login server might not be scalable and that they would have too much traffic on them.
1. Could they in theory be hosted on just a single computer? Or would it be too much traffic for 10 000+ players?
2. If they can be hosted on a single computer, will the servers still not have issues for people that live far away?
Would it be better to have the lobby and login servers per region of the world in that case?
The bad thing about that is that the players would not be able to see servers in the US if they live in Europe, and that their account and items would not exist on the other servers.
3. Might be far-fetched, but if I would rewrite both servers to instead be on a website with a database and make the client/game server do
web requests instead (such as HTTPS or calling a php with specific headers),
would it help in solving my problems somehow?
All your problems and questions are solved by serverless cloud based solution AWS Lambda e.g. or similar. In this case the scalability is not your problem. Just develop the logic. This will save you much time.
If you would like to make servers as single app hosted by your own server. Consider using something like e.g. Go instead of C++. It's designed exactly for these purposes. I mean highly loaded web/network services.
Well, this is c++ and i code in java, but maybe the logic is useful for you any way so i will tell you how i end up implementing something similar but in a casino.
In my case I have 2 diferrent sockets in the same server program, one of the sockets is TCP and it handles all logins, registers and payments, while the second socket is UDP and it handle the actual game multiple payers are playing, then you could group internally all those UDP connection in groups (probably arrays of sockets) to generate those lobbies. Doing that all your server is just one class that could run in a single pc using 2 ports (one for each socket) However this do not solve the problem of the ping for people who live far away.
If ping is a problem (not my case in a casino) you could probably host your server region base but removing the login, registration and paymets of your server and replace it for a connection to a central server (this central server should be TCP and you could also implement a https socket to also allow your webpage to connect to this server and create accounts or pay you directly from the browser)
sorry to mess your life even more, but i hope it helps
I am working on an application that, among other applications, allows users to send emails. It works by writing everything onto an SQL server, so you can have multiple instances of an application.
The email sending currently works with an "Outbox" table on the SQL server, to which application instances directly write the data with SQL statements. I have, however, hit an issue, that a requirement for attachments on the emails has arisen.
My thinking is that if I can send the attached files to a directory on which the SQL server resides (possibly the TEMP directory?), and then store the path to that file (or a UUID, if the file is constant) in the table. The issue is I have no idea particularly where to start with sending the file, as I am still vaguely new to C++.
One term I have come across is sending it with sockets, but am struggling with where to start with it and do not know if it is indeed the best option. Could anyone provide some advice on this matter?
Thanks in advance.
If I correctly understand the way it works (applications save the emails to SQL then another application takes them out and sends them) you have two choices:
Save the attachment as binary in the SQL and have the mailer application do the rest.
Use sockets to transfer the file to the SQL server and save the path to it just as you said.
I'd say option 1 would be the best option if I understood correctly the way its currently working. And as for option 2, there are probably other ways to transfer the file but sockets would be the easily cross-platform option.
Its not hard to get started with sockets, there are a lot of examples all over the internet.
winsock
more winsock
sys/socket.h
more sys/socket.h
I'm currently using Jetty as my websocket server and I'm trying to make a real-time game. I'm really new to this. So far I've managed to work on the easiest one (which is the chat). Now, I have a couple of issues:
I'm trying to make a list of the current users connected in the server; how do I make such feature? I don't really know if this is practical but my idea is that there's a time interval that lets the server know that "Hey, I'm still alive." I want my user list to be dynamic in such a way that if a user logs out, the list will refresh.
I'm also trying to make "rooms" for my app. Basically, the people in "Room 1" can't see what people in "Room 2" are doing; the other room functionalities are already self-explanatory. I still don't have an idea for this; can someone recommend a way to implement this?
So far I've been having fun in learning this technology, and I would be very glad if there would be incoming help. These two are my issues so far. I'm also open for any suggestions for my app.
Thank you all in advance. :-)
(Uhm, can #1 and #2 be solvable solely by Javascript?)
Your question isn't really jetty or websocket specific.
Websockets simply provide a transport mechanism for your web browser to communicate with the server - what gets set over that transport, and how the server manages information are completely separate to the websocket.
Firstly, if you haven't read it already, read this article: http://cometdaily.com/2010/03/02/is-websocket-chat-simple/
Secondly, consider using cometd to make this easier - version 2 (currently in Beta) supports websockets.
As for your questions - there are 2 things you'll need to do (cometd can help with this)
1. Define a protocol
Define a messaging protocol to sit on top of websockets. Websockets just provide a way to send chunks of data around, they don't define what that data means. You'll need to build something that does that, so you have messages that go from the client to the server like.
CONNECT "user"
STILL_ALIVE
JOIN_ROOM "room1"
LEAVE_ROOM
GET_USER_LIST
SEND_MESSAGE "message"
And then you need messages form the server to the client
RECEIVE_MESSAGE "user" "message"
RECEIVE_USER_LIST "room1"
You need to come up with some reliable way to send that data over a websocket. You can invent your own simple protocol (like the Jetty chat example does), you could use JSON, or XML, or CometD channels.
2. Server-Side State
If you've got simple chat working, then you must have made a start on this, but the other bit you need is a way to keep track of
how many users are connected
what their names are
which socket they're connected to
which room they're in
Depending on how complex your system is going to become, you might be able to just store that in 1 big singleton on the server.
So we have some server with some address port and ip. we are developing that server so we can implement on it what ever we need for help. What are standard/best practices for data transfer speed management between C++ windows client app and server (C++)?
My main point is in how to get how much data can be uploaded/downloaded from/to client via his low speed network to my relatively super fast server. (I need it for set up of his live stream Audio/Video bit rate)
My try on explaining number 3.
We do not care how fast is our server. It is always faster than needed. We care about client tyring to stream out to our server his media. he streams encoded (via ffmpeg) live video data to our server. But he has say ADSL with 500kb/s of outgoing traffic. Also he uses some ICQ or what so ever so he has less than 500 kb/s per second. And he wants to stream live video! So we need to set up our ffmpeg to encode video with respect to the bit rate user can provide. We develop server side and client side. We need a way of finding out how much user can upload per second currently (so value can change dynamically over time)
Check this CodeProject Article
it's dot-net but you can try figure out the technique from there.
I found what I wanted. "thrulay, network capacity tester" A C++ code library for Available bandwidth tracking in real time on clients. And there is "Spruce" and it is also oss. It is made using some of linux code but I use Boost library so it will be easy to rewrite.
Offtop: I want to report that there is some group of people on SO down voting on all questions on this topic - I do not know why they are so angry but they deffenetly exist.