[Løst]Instant messaging, hvordan?

[Joachricar]

Hei.

 

Driver å funderer litt på Instant messaging og hvordan det fungerer.

Vi har foreløpig prøvd oss på UDP, da vi tror det er den beste løsningen fordi vi slipper å holde tilkoblingen oppe hele tiden.

Prøvde oss med events på socketen, men det gikk ikke, så vi har kommet fram til diverse forskjellige løsninger:

 

1.

Kjøre igjennom en evighetsløkke, hvor socketen lytter i 1 sek, ser etter meldinger i en utboks, sender og går tilbake til lytting. Løkken avbrytes ved at vinduet lukkes.

 

2.

Sender og mottar pakker fra server med 1-5sek mellomrom, sender med pakker om det er noe i utboksen.

Serveren mottar melding og legger det i en utboks og sender til addressen.

 

3.

denne var jo å få actionlistener på socketen, men det fikk vi ikke til.

 

Noen som har noen tanker om løsningene, har noen andre løsninger eller vet hvordan vi skal få nr3 til å virke?

 

Takker for svar

Endret 24. september 2009 av Joachricar

[Joachricar]

Fant løsning her, etter mye om og men

 

http://www.daniweb.com/forums/thread36026.html#

 

Var visst ikke så vanskelig allikevel

[LostOblivion]

Threads?

[Ueland]

Threads fikser bare en bit LostOblivon

 

Skal flere bruke det må man ha en sentral server, så kan man lage systemer enten fra bunn via Sockets eller bruke ferdige løsninger som Java RMI. Sistnevnte anbefales om du studerer java og skal innom det emnet etterhvert

[Joachricar]

Går dataingeniør på HiB, men er bare 2 måneder på vei, så tror det er en stund til vi skal innom det, hehe.

Nei planen var jo å ha en server, men den skulle bare brukes til pålogging og henting av "venne lister", som inneholder IP-adressene til folk som er pålogget.

Pratingen skal gå fra klient til klient.

 

Har også tenkt på å ha alt innom server, men det blir vel mer stress for serveren?

Nei ikke i mitt tilfelle, men om det skulle ha vært mange brukere

[norpheus]

Hvis du skal kjøre IM uten å gå via en server, må du ha direkte tilkobling mellom klientene, dette krever igjen enten upnp eller åpning av port hos en av klientene.

 

Det aller meste av IM der ute gå via en sentral server, noe jeg også vil anbefale deg (gjør programmeringa noe lettere også).

 

Du trenger egentlig bare å sette opp en server som lytter etter tilkoblinger, når en tilkobling opprettes, startes en egen thread som behandler denne tilkoblingen. Deretter lager du en klient som kobler seg på serveren.

Jeg vet det ligger mange gode eksempler der ute, bruk google.

Søk på feks: "multithreaded socket server java"

 

Uansett; Lykke til!

[Joachricar]

Ja har tenkt på det og, og virker jo forsåvidt lettere, men tenker på serverbelastning da.

Men har tenkt på å ha sende som array med addresse, avsender, meldings-ID og melding.

meldings-ID skal returneres fra mottaker til avsender innen en viss tid for at avsenderen skal få vite at meldingen er mottat. Virker egentlig som den greieste måten å gjøre det på. Har for tiden direkte oppkobling mellom klientene ettersom jeg ikke har mekket noen server enda. Med en gang jeg blander inn GUI og ikke får det til gir jeg altfor lett opp, hehe. Får ikke til scrolling i JTextArea, noen som har noen tips?

 

Lager JScrollBar og legger den til text-areaet mitt og setter Vertical til when needed, men kommer ikke noe da =\

[norpheus]

Scrolling er ganske enkelt, lag et JScrollPane og legg til JTextArea på den.

Jeg tror ikke du behøver å tenke på serverbelastning. Spørs jo på hvor mange brukere man snakker om da, men noen tusen bør da gå ganske greit. Spørs vel heller på båndbredden kanskje.

I java kan du dessuten fint sende objecter ved å bruke ObjectOutputStream, som kan være enklere å bruke i dette tilfellet (definer en serializable klasse som kan inneholde de variablene du ofte trenger).

[Joachricar]

		scroll = new JScrollPane(output = new JTextArea(), JScrollPane.VERTICAL_SCROLLBAR_AS_NEEDED, JScrollPane.HORIZONTAL_SCROLLBAR_NEVER);

	output.setBounds(10, 10, 390, 200);

 

koden for scroll og textarea, har jo selvfølgelig addet de og.

Interfacet er jo bare føreløpig, kan ikke noe særlig om det, men kommer etterhvert

Men altså det med bårdbredde og serverbelatsning er bare en tenkt situasjon, vet jo selvfølgelig at det ikke kommer til å bli noen suksess dette her ^^

[Joachricar]

Oki.

 

Har fortsat litt på dette her nå og holder på med å lage server.

Forstod meg ikke helt på sending av objekter ved UDP:

 

Med senderen gjør jeg objektet om til string, og så til byte, og sender pakken med bytes.

Med mottakeren gjør jeg bytsene om til string, men derfra finner jeg ikke ut hvordan man gjør den om til ett objekt igjen.

 

Har drevet å googlet nå en stund, men finner ikke ut av det =\

Kan det skrives inn til en fil for så å hente ut dataene som objekt?

Noen som har peiling?

 

Akkurat dette ville vel vært lettere med TCP, men utifra det jeg vet kan man kun ha en tilkobling om gangen der?

Eller ville det gått med å connecte og så close connection med en gang med TCP istedet?

Tanken bak det å bruke UDP var jo akkurat det da.

Endret 29. september 2009 av Joachricar

[Patton]

I ditt tilfelle ser jeg ingen fordel med aa bruke UDP. Dette maa du implementere selv hvis du bruker UDP framfor TCP:

• Passe paa meldingene du mottar blir behandlet i riktig rekkefoelge rekkefoelge. Dvs. hvis du mottar en pakke saa maa du selv sjekke ut om den kan behandles med en gang, eller om du maa vente paa en pakke som ble sendt tidligere (f.eks. hvis du skriver "hei", og "jeg heter ola", saa kan strengene bli mottatt i rekkefoelgen "jeg heter ola", og "hei").
  
• Passe paa at pakker som forsvinner blir sendt enda en gang.
  
• ...Sikkert en del andre vesentlige ulemper som jeg ikke kommer paa naa
  

Med senderen gjør jeg objektet om til string, og så til byte, og sender pakken med bytes.

Med mottakeren gjør jeg bytsene om til string, men derfra finner jeg ikke ut hvordan man gjør den om til ett objekt igjen.

Du gjoer et objekt om til string? Hvordan?

 

Kan det skrives inn til en fil for så å hente ut dataene som objekt?

Noen som har peiling?

Hva er det du vil skrive til fil? Og hvorfor trenger du en fil, driver du ikke aa sender data over ethernet?

 

Akkurat dette ville vel vært lettere med TCP, men utifra det jeg vet kan man kun ha en tilkobling om gangen der?

En forbindelse per Socket-par ja, men du kan lage (nesten) saa mange forbindelser du vil.

 

...
SocketServer server = new SocketServer(12345);

// Lytter til alle inngaaende forbindelser paa port 12345
// Saa snart en klient kobler, saa processer den nye socket'en
// og vent paa neste
while(true) {
 Socket newConnection = server.accept();	 
 processNewConnection(newConnection);
}
...

public void processNewConnection(Socket newConnection) {
// Yay, en ny klient har koblet paa 
// Gjoer noe lurt med socketen, som f.eks. hive den
// inn i en liste over aktive forbindelser, eller
// lag en ny thread som overvaaker forbindelsen 
}

[Joachricar]

Oki, drev egentlig bare å rotet med alt mulig pga frustrasjon, hehe.

Gir lett opp om jeg ikke får ting til.

 

Fil-greiene var bare noe jeg fant på google, men ble jo bare rot.

 

Glem alt annet jeg sa, starter på nytt med socketsene nu.

 

Så, du vil ha TCP.

For hver tilkobling serveren får, da må vel den sjekke om porten er ledig, og om ikke, mekker den ny port.

Om jeg har forstått deg riktig her vil det jo bli mange porter etterhvert?

 

Om ikke, gidder du forklare hvordan?

eller gi meg en lenke?

 

EDIT:

 

http://tutorials.jenkov.com/java-multithre...ded-server.html

fant dette, ser litt på det.

Endret 30. september 2009 av Joachricar

[Cyberfrog]

Serveren trenger bare en port, som alle klientene bruker.

[Joachricar]

Ja fant ut av det ved hjelp av linken over.

Uten multithreaded funket det ikke ihvertfall, om du har en løsning på det hadde det vært flott^^

[Patton]

I prinsipp trenger du minst 2+n Threads, hvor n er antall klienter/Sockets.

 

Den ene traaden lytter bare paa porten og starter en ny traad per tilkobling:

while(true) {
 Socket newConnection = server.accept();	
 processNewConnection(newConnection);
}

Denne traaden boer gjoere minst mulig slik at ServerSocket.accept() blir kalt opp saa snart saa mulig.

 

 

Klient-traadene (n) har som hovedoppgave aa lese Socket.inputStream. Siden InputStream.read() blokkerer, boer traadene ikke gjoere saa mye annet.

 

 

Hovedtraaden samler all informasjon fra klient-traadene (som de faar ved InputStream.read()), behandler dem og sender dem videre til klientene (Socket.OutputStream.write()).

 

NB! Socket.OutputStream.write() kan faktisk blokke, hvis klienten som mottar streamen (og kaller Socket.InputStream.read()) ikke leser kjapt nok. I noen tilfeller kan det oppstaa brudd paa forbindelsen mellom to Sockets, uten at den ene (eller begge) merker dette (typisk ved hardware problem, f.eks. en defekt switch). Da vil Socket.OutputStream.write() blokke paa et gitt tidspunkt. Siden du implementerer Server og klient selv, saa ville jeg innfoert en heartbeat for aa sjekke om forbindelsen er "alive", og manuell lukke en Socket hvis forbindelsen er doed.

 

For aa vaere 100% sikker paa at hovedtraaden ikke blokkeres, saa maa du lage 2 traader per paakoblet klient, en for read() og en for write() (ville jeg ignorert i foerste omgang).