Toon posts:

[Java] Een probleem met DatagramSockets.

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hoi, ;( ;( ;(

De doelstelling van mijn opgave B) is het programmeren van een Client/Server architectuur die moet instaan voor het transport van data over UDP. Zoals jullie weten B) biedt UDP geen betrouwbare bestandsoverdracht , wat TCP wel heeft. Bijgevolg zal ik een "timeout" feature moeten inbouwen.

De communicatie tussen de client en de server is reeds operationeel. Telkenmale de Client om een datapakket vraagt (aan de server) start er tevens een nieuwe thread (Watchdog), die moet instaan voor de timeout.

Wanneer de server uitvalt blijft de client wachten op data. Dit is uiteraard niet de bedoeling, hij moet telkenmale een nieuwe aanvraag indienen. Dit los ik uiteraard op door de Watchdog te gebruiken. Die moet een pakket versturen naar de client, zodanig dat deze stopt met blokkeren (en dit na een vooraf gedefinieerde tijd (timeout)). Het deblokkeren gebeurt dus door een DatagramSocket te gebruiken op de lokale host die de receive (client) deblokkeert. Hiervoor moet de Watchdog weten naar welke socket hij moet sturen (namelijk dezelfde als degene die hij gebruikt om data van de server te ontvangen). Dus moet de client zich eerst kenbaar maken aan de hond, wat ik wil doen door telkenmale bij het oproepen van de watchdog een datagram van de client te versturen. Op die manier heeft hij zijn IP/poort.

Folders:
Client > ClientMain.java, Watchdog.java, Reminder.java
Server > ServerMain.java

Dit is wat ik reeds heb gedaan. Mijn probleem nu is het feit dat ik geen socket.receive(cReceivePacket); kan definiëren in mijn Watchdog ;( . Hier ziet u de foutmelding:

http://users.skynet.be/lve/Fout.JPG .

Ik heb tevens de client en server bestanden geuploaded: spam

Start eerst de server met als parameter een poort (willekeurig).
Start vervolgens de client met als paramaters: IP server, poort en timeout.

Mijn vorige thread werd gelokt, hopelijk gebeurt dit nu niet. De informatie met wat ik al dan niet heb gedaan en geprobeerd is nu immers aanwezig!

Ik vraag niet om een oplossing, ik vraag enkel hoe het komt dat ik in de watchdog geen ontvangende socket kan declareren. De foutmelding maakt mij tevens niets wijzer.

Dank bij voorbaat,
Luk :> :> :>

[ Voor 13% gewijzigd door whoami op 29-11-2003 18:28 ]


  • whoami
  • Registratie: December 2000
  • Nu online
Java kent zoiets als 'checked exceptions'.

Dit wil dus zeggen, dat een methode specifieert welke exceptions die allemaal kan 'throwen'. Een eis om uw applicatie dus te kunnen compileren, is dat je er voor zorgt dat die excepties (die die door die method dus kunnen gethrowed worden) afgehandeld worden.

Je zult dus ff in je help/manual/whatever moeten kijken welke excepties 'Receive' dus allemaal throwed. (Volgens die foutmelding throwed die dus alleszins een IOException).
Je zult dus exception-handling code moeten schrijven die deze exceptie opvangt mocht deze zich voordoen. Aangezien jij dat dus niet doet, weigert jouw code te compileren.

Praktisch gezien is jouw probleem dus makkelijk als volgt te verhelpen:
pseudo-code:
code:
1
2
3
4
5
6
7
8
9
try
{
    socket.receive(blaat);
}
catch( IOException e )
{
   // doe hier error-handling
   // mocht de IOException zich voordoen
}


Had je trouwens die foutmelding al eens opgezocht in je help ofzo?

[ Voor 10% gewijzigd door whoami op 30-11-2003 21:29 ]

https://fgheysels.github.io/


Verwijderd

Topicstarter
Ja hij geeft nu geen fouten. Bedankt :> .
Het vreemde is wel dat ik in mijn client/server geen exception handelingen moest voorzien. 'k Heb tevens nooit Java gehad op school dus ben ik daar vrij nieuw in, 'k weet hoe excepties werken maar 'k wist niet dat het een noodzaak was. Allez, bedankt hé ..

Ik heb de foutmelding van receive opgezocht en daar stond enkel SocketException bij.

[ Voor 17% gewijzigd door Verwijderd op 29-11-2003 18:30 ]


  • Gert
  • Registratie: Juni 1999
  • Laatst online: 05-12-2025
Dat komt waarschijnlijk omdat het een mogelijke IOExceptie van een onderliggend object doorstuurd, het creeert de exceptie niet zelf.

[ Voor 4% gewijzigd door Gert op 29-11-2003 22:53 ]


  • whoami
  • Registratie: December 2000
  • Nu online
Gert schreef op 29 november 2003 @ 22:53:
Dat komt waarschijnlijk omdat het een mogelijke IOExceptie van een onderliggend object doorstuurd, het creeert de exceptie niet zelf.
Logisch gezien zou die receive functie dan toch die IOExceptie moeten afhandelen mocht dat zo zijn? :?

https://fgheysels.github.io/


  • Robtimus
  • Registratie: November 2002
  • Laatst online: 19:57

Robtimus

me Robtimus no like you

whoami schreef op 30 november 2003 @ 21:43:
[...]


Logisch gezien zou die receive functie dan toch die IOExceptie moeten afhandelen mocht dat zo zijn? :?
De header, uit de API geplukt:
Java:
1
public void receive(DatagramPacket p) throws IOException
Throws:
IOException - if an I/O error occurs.
SocketTimeoutException - if setSoTimeout was previously called and the timeout has expired.
PortUnreachableException - may be thrown if the socket is connected to a currently unreachable destination. Note, there is no guarantee that the exception will be thrown.
IllegalBlockingModeException - if this socket has an associated channel, and the channel is in non-blocking mode.
Goed gedocumenteerd lijkt me

More than meets the eye
There is no I in TEAM... but there is ME
system specs


  • whoami
  • Registratie: December 2000
  • Nu online
IceManX schreef op 30 november 2003 @ 21:56:
[...]
De header, uit de API geplukt:
Java:
1
public void receive(DatagramPacket p) throws IOException

[...]
Goed gedocumenteerd lijkt me
Dat is idd het logischste natuurlijk. Ik vond het al vreemd dat de compiler ging gaan klagen over een mogelijke exceptie die niet afgehandeld wordt, als die method die exceptie niet throwed.

De topicstarter heeft dus blijkbaar niet goed in de documentatie gekeken. :P

edit:

[offtopic]
Hmmm.... dit is m'n 10.000 P&W post. :X
[/offtopic]

[ Voor 8% gewijzigd door whoami op 30-11-2003 22:03 ]

https://fgheysels.github.io/

Pagina: 1