---

Hej

Følgende if-statement returnerer aldrig true, selvom jeg ved der ligger data
klar i readeren "in". Hvordan kan et være? Jeg kan fjerne if-statement'et og
så får jeg den ønskede streng ved readLine()-kaldet. "in" er lavet ud fra en
Socket.

if(in.ready())
{
line = in.readLine();
}

Jacob

---

Jacob Jensen wrote:
> Følgende if-statement returnerer aldrig true, selvom jeg ved der ligger data
> klar i readeren "in". Hvordan kan et være? Jeg kan fjerne if-statement'et og
> så får jeg den ønskede streng ved readLine()-kaldet. "in" er lavet ud fra en
> Socket.
>
> if(in.ready())
> {
> line = in.readLine();
> }

Hvorfor læser du ikke bare ?

readLine er blocking d.v.s. at den venter på at der er noget.

Og hvis du ikke vil blocke med en socket skal du alligevel
over i noget nio.

Arne

---

> readLine er blocking d.v.s. at den venter på at der er noget.

Præcis. Jeg vil ikke blokere.

> Og hvis du ikke vil blocke med en socket skal du alligevel
> over i noget nio.

nio? Hvorfor det?

Jacob

---

"Jacob Jensen" <omo@adslhome.dk> writes:

> > readLine er blocking d.v.s. at den venter på at der er noget.
>
> Præcis. Jeg vil ikke blokere.

Kan du ikke proeve at vise lidt mere af din kode? Hvorfor vil du ikke
blokere?

> nio? Hvorfor det?

Hvis du ser eksemplet fra linket nedenunder - ved run() metoden, saa er
den "normale" maade at lave non-blocking paa at man bruger en selector til
at lytte paa IO "events" og saa laeser/skriver paa den IO kanal der fik
eventet -- Og, det bruger man java.nio til i Java
http://shorterlink.com/?3574CM

Mvh,
Soren

---

> Kan du ikke proeve at vise lidt mere af din kode? Hvorfor vil du ikke
> blokere?

Jeg har en ServerSocketChannel som jeg kan lave non-blocking accept() på.
Det fungerer fint og så står jeg med en SocketChannel hvis det går godt. Jeg
tager den Socket som er tilknyttet denne SocketChannel og gemmer den et godt
sted :) Lige nu har jeg kun en enkelt, men der kan komme flere.

Det er så disse Socket's jeg gerne, sådan ind imellem, vil læse fra uden at
blokere. Hvis der ikke er noget data er jeg ligeglad. Hvis der er data vil
jeg gerne have en "linje" (afsluttet med "\r\n").

Hvorfor er det forkert at bruge BufferedReader? Hvorfor virker det ikke?

> Hvis du ser eksemplet fra linket nedenunder - ved run() metoden, saa er
> den "normale" maade at lave non-blocking paa at man bruger en selector til
> at lytte paa IO "events" og saa laeser/skriver paa den IO kanal der fik
> eventet -- Og, det bruger man java.nio til i Java
> http://shorterlink.com/?3574CM

Jeg ville nok kunne gøre det samme med en selector, men det undrer mig
hvorfor det her ikke fungerer. Det er kun ready() jeg har problemer med,
uden den burde da kunne tjekke available() fra den underliggende InputStream
som min Socket har givet mig.

Jeg har ikke lige styr på selectorer, men det kan jo blive nødvendigt :)

Jacob

---

Jacob Jensen wrote:
> Jeg har en ServerSocketChannel som jeg kan lave non-blocking accept() på.
> Det fungerer fint og så står jeg med en SocketChannel hvis det går godt. Jeg
> tager den Socket som er tilknyttet denne SocketChannel og gemmer den et godt
> sted :) Lige nu har jeg kun en enkelt, men der kan komme flere.
>
> Det er så disse Socket's jeg gerne, sådan ind imellem, vil læse fra uden at
> blokere. Hvis der ikke er noget data er jeg ligeglad. Hvis der er data vil
> jeg gerne have en "linje" (afsluttet med "\r\n").
>
> Hvorfor er det forkert at bruge BufferedReader? Hvorfor virker det ikke?
>

> Jeg ville nok kunne gøre det samme med en selector, men det undrer mig
> hvorfor det her ikke fungerer. Det er kun ready() jeg har problemer med,
> uden den burde da kunne tjekke available() fra den underliggende InputStream
> som min Socket har givet mig.
>
> Jeg har ikke lige styr på selectorer, men det kan jo blive nødvendigt :)

Min erfaring er at man skal undgå available/ready metoderne
for sockets.

Implementationen er ikke god for sockets. Og jeg tror iøvrigt heller
ikke at det er nemt at lave en god implementation.

Men jeg er ret sikker på at du vil få en kønnere og
mere robust kode ved at bruge tråde og blocking readLine.

nio og selector er lavet for at kunne håndtere rigtigt
mange socket connections.

Arne

---

> nio og selector er lavet for at kunne håndtere rigtigt
> mange socket connections.

Ja, jeg skal håndtere maksimalt 4 Sockets. Jeg har ikke brug for at de
bliver varataget i forskellige threads (faktisk vil jeg gerne helst undgå
det). Hvordan bruger jeg selector i dette tilfælde? Jeg har som sagt en
ServerSocketChannel som jeg laver non-blocking accept() på og det fungerer
fint. Så står jeg med en SocketChannel som jeg gerne, ind imellem, vil kunne
læse fra uden at blokere hvis der ikke lige er data på den. Jeg brugte
primært BufferedReader fordi den har en readLine().

Jacob

---

"Jacob Jensen" <omo@adslhome.dk> writes:

> Det er så disse Socket's jeg gerne, sådan ind imellem, vil læse fra uden at
> blokere. Hvis der ikke er noget data er jeg ligeglad. Hvis der er data vil
> jeg gerne have en "linje" (afsluttet med "\r\n").

Du kunne også lave en tråd pr socket, og lade hver af dem blokere.
--
Thorbjørn Ravn Andersen

---

Jeg har brug for at kunne læse "linjer" af tekst fra denne Socket, og jeg
har brug for ikke at blokere hvis der ikke lige ligger noget data klart. Så
vidt jeg har læst mig til burde BufferedReader kunne ordne det for mig:

Min "in" bliver oprettet således:

in = new BufferedReader(new InputStreamReader(socket.getInputStream()));

Jacob

---

Jeg undrer mig mere og mere... Jeg har en klasse som har en variabel af
typen Socket... Kan det virkeligt være rigtigt at denne klasse ikke selv kan
finde ud af om der ligger data klar? Hvis den kan, er kan det så KUN ske med
selectors? Det virker som overkill når det kun drejer sig om én socket. Hvis
det er eneste mulighed, hvordan gør jeg det så helt konkret?

Hvad hvis den havde en variabel af typen SocketChannel istedet?

Jacob