Chatt - Många till många
 

Letar efter chatt-motor som kan hantera "många till många"-chatt. Ska finnas på en sajt där man kan logga in och sen välja rum. Det kommer väl finnas 10-20 rum att välja på. Det ska rulla på en Windows 2008 server och helst vara skriven för ASP.NET. Databas MSSQL.

Jag har hittat http://www.aspnetajaxchat.com samt http://cutesoft.net/ASP.NET+Chat/ som ser bra ut båda två men kostar en hel del samt källkoden kommer inte med. Köper gärna i framtiden men just nu är det på experimentstadiet så jag vill gärna hitta något billigare eller open source.

Finns det något som ni kan tipsa om? Bygger gärna vidare på något befintligt om ni känner till en bra grund. Även om jag helst vill ha ASP.NET så tar jag gärna mot tips på PHP-lösningar också.

Webbaserad irc-klient?

Finns ett flertal Java, Ajax & Flash baserade IRC klienter som är fria.

Webbaserad IRC är helt klart lösningen.

När det gäller IRC så är mina kunskaper begränsade men som jag förstår det så behöver IRC en egen server. Stämmer det? Någon som kan sparka mig åt rätt håll så man kommer igång?

Du kan använda en kanal på något av de nätet som finns redan, dalnet, linknet, efnet, quakenet etc.

Alltså behöver du inget mer än din webbserver som hostar IRC-klienten.

Tyvärr innebär detta med IRC att jag inte har kontroll på vad som skrivs (om jag förstår det rätt). Jag vill kunna spara detta i 2-5 dagar innan det raderas. Kanske kommer jag tillbaka till IRC-lösningen men tillsvidare letar jag en lösning där jag bla kan använda MSSQL-databas för att lagra chatten. Jag uppskattar dock era tips. Får mig att tänka till.

Nackdelen med att spara chattraderna i en databas är att det riskerar att kräva rätt mycket av chattsystemet. Bättre i så fall är nog, som många redan påpekat, att använda sig av IRC. Du kan lätt sätta upp en egen IRC-server med loggning. Även om du använder en publik server finns det ingenting som hindrar dig från att själv vara inne i kanalen och logga allt som skrivs.

Den stora fördelen med IRC är att det är byggt för det du vill göra och är beprövat.

Om du väljer att köra med en annan lösning med databas och skript så riskerar det att bli prestandakrävande. Att ha en många-till-många-chatt där allt som skrivs läggs in och läses från en SQL-databas skalar otroligt dåligt. Vid bara något tiotal användare tippar jag på att du kommer börja få problem om du inte har en överdrivet snabb server (och att kasta hårdvara på ett mjukvaruproblem är ju som vi vet rätt onödigt...).

Jag har gjort en enkel chatt-klass som är gratis och open source.
http://www.aspsidan.se/default.asp?p...criptSubCat=36

Den lagrar förvisso inget i databas, och har inte flera chattrum, men är så enkelt byggd att du säkert förstår hur du kan utöka den. Om inte står mina konsulttjänster till förfogande.

Tack Stefan, ska titta på det men även på IRC-lösningen som flera rekommenderar. Uppskattar all input jag har fått.

Är det viktigt att du lagrar i db och i så fall varför? Det är ett dåligt alternativ såvida det inte är nödvändigt och du räknar med få samtidiga användare (i så fall kan man väl kanske ifrågasätta nyttan av en chatt från första början :)).

Vill lagra ifall det blir prata om vad som är sagt. Å andra sidan kanske det är onödigt...

Orsaken till chatt-lösning är att folk ska kunna kommunicera i olika rum i realtid utan att behöva använda IRC-klienter etc. Berättar gärna senare vad det ska användas till eftersom domän ännu inte är registrerad men folk med samma intressen kan mötas och prata i realtid. Lösningen ska vara enkel, inloggning och sen direkt till chatten samt kunna välja olika rum. Gärna möjlighet till smilly osv. Loggning kan man lägga till efteråt om det skulle behövas.

Det jag har hittat och som kommer närmast är de som jag nämner på första sidan, http://www.aspnetajaxchat.com samt http://cutesoft.net/ASP.NET+Chat/ men allra helst skulle jag villja ha källoden också så man kan anpassa och förbättra enligt sina egna tankar och idéer.

@StefanBergfeldt Är verkligen IIS och .NET lämpligt att bygga en chatt i? Jag har svårt att tro att den platformen passar bra att köra många parallella requests som en HTTP-baserad chatt kräver, men å andra sidan har jag ingen koll på MS-grejer.

Om man inte har så höga krav och är bekväm med Javascript så borde det vara snabbt gjort att slänga ihop något i node.js.

Varför skulle inte IIS och .NET klara av requests?

http://weblogs.asp.net/scottgu/archi...P.NET-2.0.aspx

APE (Ajax Push Engine) Server.

Tack för alla tips och tankar. Jag ville först och främst ha igång något snabbt för att sedan utvärdera intresset. Blir intresset stort får man utveckla applikationen men jag vill inte lägga ner förmycket tid och pengar innan man vet hur det går.

Det blev tills vidare Cute Chat eftersom den var enklast att komma igång med. Asp.net ajax chat var mindre bra bla pga hantering av användare.

På www.tvchatt.se ser ni vad jag hade för ide... :) Den är inte klar men första steget är igång.

Har du kollat på http://aspnetjquerychat.codeplex.com/?

Går själv och funderar på att skriva om en befintlig lösning utifrån den lösningen. Man får ändra en hel del själv dock men det såg inte så himla bökigt ut.

Det är ju knappast en självklarhet. Enligt den här artikeln verkar det dock gå att göra: http://www.sprklab.com/notes/14-long...et-in-asp.net/

Förresten förstår jag inte relevansen av artikeln du postade. För att kunna generera stora volymer av vanliga webbsidor behöver man inte kunna hålla i många (åtminstone tusentals) HTTP-requests samtidigt som en HTTP-baserad chattserver behöver.

Eftersom en och en halv miljard sidvisningar per dygn betyder mer än femton tusen sidvisningar i sekunden, så tycker jag nog att vi kan dra paralleller?

Både IIS och ASP.NET är byggt för att prestera bra i storskaliga system, så jag förstår inte riktigt varför det inte skulle fungera.

Jag har tittat men det var snabbt. Fick uppfattningen att de mer var en supportchatt. Fungerar min idé så kanske jag ska titta närmare på den. Båda de två chatt-system som jag har tittat på har sina fel och brister och jag vill gärna ha kontroll på koden.

Och facebook kör 10 gånger mer trafik med apache och PHP på de vanliga appservrarna. Det betyder inte att de, liksom de flesta andra, inser det olämpliga i att använda detsamma till chatt-tjänsten. Det finns olika egenskaper både hos språk och webbservrar vilket gör dom mer eller mindre lämpade för olika användningsområden. Varken apache eller IIS är ett smart val om du ska hålla igång en stor mängd anslutningar. Men vill man så, visst, man kan köpa in 5 gånger fler servrar.

Källa?
Jag har då aldrig läst att Facebook använder Apache.

Förr presenterade sig Facebook som Apache 1.3.37 i HTTP-huvudet (fast med någon "-fb2" eller liknande på slutet, antagligen för deras egna patchar).

Enligt Slashdot verkar det som att HipHop som de kör nu även hanterar HTTP:
http://developers.slashdot.org/story...-PHP-Webserver

En vild gissning är att de slutat använda Apache på senare tid.

I princip alla tal eller publikationer de gjort senaste åren om sin teknik, vilket är ganska många. Jag lyssnade på ett i våras på FOSDEM där jag är rätt säker på att de nämnde det, finns på http://video.fosdem.org/2010/maintracks/.

Det kan nog stämma att allt är flyttat till HipHop nu. I våras hade de flyttat över runt 50% har jag för mig. De hade med Apache, liksom MySQL eller Memcached, patchat deras värsta problem med mjukvaran varför det låg en -fb2.

MySpaces webbservrar genererar en sida på ca. 0,2s och genererar således några fåtal sidor parallellt per CPU. Det är väldigt annorlunda än mot att hålla i 20000 parallella requests som HTTP long polling kan medföra.

Varför long polling?
Min chatt bygger på att hämta ny data ofta. Det blir inte push på riktigt, men å andra sidan kan dom flesta nöja sig med att det tar en sekund att leverera meddelanden.

Lämpligtvis använder man till exempel json för att överföra data, för att minska mängden overhead som skickas fram och tillbaka.

1.) Long polling är effektivare då du slipper extra anslutningar, som ger stor overhead för router+brandvägg+OS+webserver+applikation, och extratrafik från klienten i större mån. Det är fördel för både klient och server. Att man sedan får snabbare responstider är en trevlig sideffekt (upp till poll time snabbare).
2.) IIS (och apache) kommer alltid vara enorm overhead för applikationer där det bara är webbservern och en väldigt enkel datahämtning ("hämta nya meddelanden sedan x skrivna till y") som behövs.
3.) Trafikmängden tillbaka till klienten är väldigt sällan något större problem men påverkar såklart kostnaden en del och JSON kan du välja oavsett anslutningsmetoder.

Web sockets är på väg av en anledning. Comet är hypat av en anledning.

Med tjänsten Beacon (http://beaconpush.com/) kan man slänga ihop en realtids-chatt med kanaler på ett par timmar (som inte kräver java eller flash och som även fungerar på iphone/android). Beacon är en tjänst för att pusha meddelanden till användare via websockets (med fallback på longpoll och flash sockets), utan att behöva köra sin egen comet-server (man pushar ut meddelanden genom att göra HTTP-anrop till beacon's API).

Full disclosure: Jag jobbar på ESN, företaget som bl.a. utvecklar Beacon.

http://www.wn.se/t3490.html §3 kan vara intressant att läsa.

Det känns som att det relativt enkelt borde gå att göra en ajaxlösning med hjälp av t.ex. jQuery för själva chatdelen, sen att skapa de olika chatrummen som vanliga webbsidor, alltså t.ex. chatsidan/valet2010.se är ett chatrum och chatsidan/nintendo.se är en annan. Då kan du även spara och radera inläggen hur du vill i en sql databas som du själv har kontroll över.

Tack, jag hade några idéer men jag ville komma igång snabbt. Nu rullar sidan så det går att testa. Ska börja lättar marknadsföring av den snart. Om det går bra så kanske jag ska titta på egen lösning och ska då titta på dina tips.

Hojta till om du behöver hjälp!

Inte omöjligt... :)

Jag tycker att min länk är mycket relevant för diskussionen, och jag skrev den som ett tips till trådskaparen och andra som kan tänkas vara intresserade. Med andra ord hade jag tipsat om samma sajt även om jag inte själv varit involverad över huvud taget, förutsatt att jag känt till sajten.

Men om moderatorerna anser att det är reklam/spam som inte tillför något så är det ju bara att de plockar bort/editerar mitt inlägg.

Ska titta på detta också. Alltid roligt att lära sig något nytt. :)

När jag testade era tjänster i somras fick jag inte att fungera korret. Det funkade bra de första anropen men sen fick man "Fel" och någon form av anslutningsproblem.

Då testade jag bara de mest simpla saker.

Är det fel som ni vet om eller var det bara jag som gjorde fel?

I början av sommaren hade tjänsten precis kommit ut som beta, och var lite "skakig". Det har dock hänt väldigt mycket på Beacon-projektet på senaste tid. API:et har befästs (under tidig beta gjordes ett par API-förändringar), och tjänsten rullar nu på mycket stabilt. Beacon använder sig av get satisfaction för support, och man får i regel svar mycket snabbt.

För intresserade kan jag upplysa om att jag gjort en wordpress-plugin som använder sig av Beacon. Den gör att man blir notifierad om nya kommentarer på en bloggpost utan att behöva ladda om själva bloggpostsidan. Jag gjorde den mest i proof-of-concept-syfte, och det ska sägas att jag enbart har testat den på Wordpress 2.9.2. Finns iaf på: http://github.com/heyman/beacon-wordpress

Beaconpush verkar vara en riktigt bra tjänst! Grymt jobbat!

Kan starkt rekommendera Beacon, fungerar ypperligt bra.
Migrerade över från APE till Beacon på drygt en timma för några månader sedan.

Kör Beacon Push för Radiofy-projektet, vilket fungerar förträffligt bra. Fördelen gentemot te.x Node.js och APE är att man själv slipper hosta servern. Jag hade riktiga problem med att te.x APE-demonen gick ner en gång i månaden, varför lyckades jag aldrig lista ut.