[Java] connectie tussen 2 Sockets zonder ServerSocket?

[Robtimus]

Is het mogelijk om, zonder gebruik te maken van een ServerSocket, een directe verbinding tussen 2 Sockets te maken? Of is de ServerSocket altijd nodig om 2 Sockets met elkaar te verbinden?

Ow, en kan ik ook (redelijk) synchrone communicatie tussen sockets? Dus niet dat ik in de ontvangende kant een pauze inbouw, maar de zendende kant direct alles op de lijn pompt?

[ Voor 33% gewijzigd door Robtimus op 03-04-2004 14:09 ]

[Verwijderd]

Je hebt volgens mij altijd een ServerSocket nodig.

Als de 2 sockets verbonden zijn, kun je aan beide kanten een InputStream en een OutputStream opvragen. Wat je daar dan verder mee doet moet je zelf weten.

[kasper_vk]

Directe verbinding tussen 2 normale sockets? Niet mogelijk voor zover ik weet; waarom zou je dat willen? Wat is het bezwaar tegen een ServerSocket?

Hoe bedoel je dat met die pauze precies? Dat de ontvangende kant niet blockt om te 'wachten' op input of iets dergelijks? Dan denk ik aan een aparte thread die dus toch gaat zitten wachten.

[Robtimus]

kasper_vk schreef op 03 april 2004 @ 14:14:
Directe verbinding tussen 2 normale sockets? Niet mogelijk voor zover ik weet; waarom zou je dat willen? Wat is het bezwaar tegen een ServerSocket?

Vereist in mijn situatie wat meer werk. Los ik wel op denk ik.

Hoe bedoel je dat met die pauze precies? Dat de ontvangende kant niet blockt om te 'wachten' op input of iets dergelijks? Dan denk ik aan een aparte thread die dus toch gaat zitten wachten.

De ontvangende kant moet juist blocken; het gaat mij erom dat de verzendende kant OOK blockt. Dat doet hij standaard NIET.

[Infinitive]

Server socket is >noodzakelijk<. De server socket geeft aan dat je namelijk aan een poortje aan het luisteren bent. Voor elke inkomende connectie genereerd de server socket een 'sessie' socket, waarvan er meerdere gelijktijdig kunnen bestaan (meerdere connecties tegelijk is mogelijk). Dus 1 socket aan de kant van de server is niet voldoende.

De verzendende kant laten blocked gaat niet zomaar. Je operating system zal namelijk buffer spelen, dus voordat 'ie kan blocken ben je vast een heleboel megabytes verder.

[ Voor 10% gewijzigd door Infinitive op 03-04-2004 16:11 ]

[Eelke Spaak]

ServerSocket is noodzakelijk als je daadwerkelijk netwerkverkeer wil gaan gebruiken.

Kijk anders eens naar PipedInputStream en PipedOutputStream, misschien doen die wel wat je wil.

quote: http://java.sun.com/j2se/.../io/PipedInputStream.html

PipedInputStream
A piped input stream should be connected to a piped output stream; the piped input stream then provides whatever data bytes are written to the piped output stream. Typically, data is read from a PipedInputStream object by one thread and data is written to the corresponding PipedOutputStream by some other thread. Attempting to use both objects from a single thread is not recommended, as it may deadlock the thread. The piped input stream contains a buffer, decoupling read operations from write operations, within limits.

[Robtimus]

Helaas zullen de 2 threads in verschillende VM's draaien, en aangezien de een een reference naar de ander nodig heeft zal dat niet lukken.

Misschien moet ik anders wat meer low level gaan werken.

[Eelke Spaak]

Je kan ook overwegen om gewoon de ene applicatie een ServerSocket te laten starten en de andere daarmee te laten connecten. Dan kan je met ServerSocket.accept() (returns Socket) gewoon doen wat je wil.

Of zijn de twee applicaties identiek?

[Robtimus]

Absoluut niet identiek, maar dat wachten op de connectie in de server kwam in mijn eerdere ideeen wat minder goed uit. Toch maar eens mijn ideeen aanpassen

[Verwijderd]

Misschien als je wat meer verteld over wat voor applicatie je aan het maken bent we je misschien wat meer suggesties kunnen geven over de aanpak en mogelijkheden

[Robtimus]

Verwijderd schreef op 03 april 2004 @ 20:23:
Misschien als je wat meer verteld over wat voor applicatie je aan het maken bent we je misschien wat meer suggesties kunnen geven over de aanpak en mogelijkheden

Realtime Distributed Shared Dataspace (hele mond vol .

Voorlopig ff niet distributed, om het wat makkelijker te houden.

Werking: ene applicatie ("clients") stuurt verschillende berichten periodiek naar de space ("server"). Periode per soort dus. Er komt 1 thread per soort bericht, die de berichten afhandelt, en eventueel berichten (weer periodiek) terugstuurt.

Nu was het idee dus dat het ontvangen en versturen van berichten ook in de threads zit, dus ook 1 connectie per thread. Alleen die threads wou ik dus wel al aan het allereerste begin van de applicatie creeren en schedulen om de overhead tijdens het echte draaien te verminderen. Maw de threads worden eerder gecreeerd dan de connecties die ze gaan gebruiken.

[hobbit_be]

Beter effe NIO gebruiken. Al that thread gedoe is a major pain voor performance. Met NIO kan je zowat alle dinges die je zou willen met een "gewone" API. Tis nou net performant om GEEN threads te gebruiken voor netwerk: gewoon 1 connectie Server - Client en dmv de taal die ze spreken alles mooi te doen verlopen...

[Robtimus]

Dus jij zegt, creeer een ServerSocketChannel dmv ServerSocketChannel.open(), gebruik ServerSocketChannel.socket() om een ServerSocket te krijgen, bind die aan mijn gewenste adres (poort) en gebruik dan ServerSocketChannel.accept() voor een connectie?
En aan de client kant SocketChannel.open(SocketAddress) om daarmee te connecten?

Wat is dan precies het verschil met sockets??

[hobbit_be]

NIO zijn gewoon low level sockets die werken zoals quasi elke andere Socket API. (ie 1 thread can multiple connections aan (trust me je wilt geen 35 threads voor 35 connections ) Op socket level zijn de NIO natuurlijk gewoon sockets maar je kan er veel meer low-level mee instellen en ze zijn absurd veel sneller. (op mijn 450Mhz kan ik bijvoorbeeld 1000clients aan die constant (>5* seconden) een message sturen naar alle anderen). Maar lost je "probleem" van geen ServerSockets dus idd niet op, omdat dat nou eenmaal ook niet kan in een server-client opstelling. Gewoon een tip om de oude Threads te laten liggen voor wat ze zijn.

[Robtimus]

Aan die threads ontkom ik niet hoor, aangezien de interweaving van message handling juist aan bepaalde constraints ligt. Eerder binnenkomen hoeft nog niet te betekenen eerder moeten eindigen.

Enne, hoe wou jij dan het (in parallel) afhandelen van messages van de connecties doen zonder threads?

Maar als die NIO idd zoveel sneller is, dan zal ik echt wel die gebruiken

[Verwijderd]

IceManX schreef op 04 april 2004 @ 18:27:

Enne, hoe wou jij dan het (in parallel) afhandelen van messages van de connecties doen zonder threads?

Als je nou eerst even wat meer over NIO gaat lezen op de site van sun dan kom je vanzelf achter het antwoord op je vraag... NIO maakt het juiste mogelijk om via 1 thread vele (denk aan 5000) connecties te verwerken zonder dat je daar vele threads voor nodig hebt.

[ Voor 12% gewijzigd door Verwijderd op 04-04-2004 20:39 ]

[Alarmnummer]

IceManX schreef op 03 april 2004 @ 20:40:
[...]
Realtime Distributed Shared Dataspace (hele mond vol .

Je hebt al gekeken naar Javaspaces, en nog een link?

[ Voor 14% gewijzigd door Alarmnummer op 04-04-2004 21:13 ]

[Robtimus]

Alarmnummer schreef op 04 april 2004 @ 21:00:
[...]

Je hebt al gekeken naar Javaspaces, en nog een link?

Ja, ik heb zelfs de specs op mijn HD op school staan.
Maar al in hoofdstuk 1 (Introduction) van het verslag zal komen te staan: "RGSpace (naam van het project) is not a JavaSpace"
(want de voorloper, GSpace, was dat ook absoluut niet)

[ Voor 7% gewijzigd door Robtimus op 04-04-2004 21:17 ]

[Alarmnummer]

IceManX schreef op 04 april 2004 @ 21:16:
[...]
Ja, ik heb zelfs de specs op mijn HD op school staan.
Maar al in hoofdstuk 1 (Introduction) van het verslag zal komen te staan: "RGSpace (naam van het project) is not a JavaSpace"

En ik dacht nog een goeie beurt te maken

De naam van jullie project deed me meteen denken aan Javaspaces, dus vandaar. En verder is het ook redelijk onbekend, want ik had er tot een maand geleden, nooit van gehoord.

Wat is in het kort het verschil tussen Javaspaces en jullie project?

[Robtimus]

Alarmnummer schreef op 04 april 2004 @ 21:23:
[...]

En ik dacht nog een goeie beurt te maken

De naam van jullie project deed me meteen denken aan Javaspaces, dus vandaar. En verder is het ook redelijk onbekend, want ik had er tot een maand geleden, nooit van gehoord.

Wat is in het kort het verschil tussen Javaspaces en jullie project?

1) geen matching op subtypes (zat niet in GSpace, dan ook niet in RGSpace)
2) geen transacties (nog)
3) "A read request acts like a readIfExists except that it will wait until a
matching entry is found or until transactions settle, whichever is longer, up to
the timeout period." Niet in RGSpace, niet aanwezig => return null
4) geen support voor snapshot
5) distributie van data is verschillend en configureerbaar per "entry" type (bv type 1 wordt alleen in node 1 opgeslagen, type 2 in alle nodes, etc)

Er zullen er nog wel een paar zijn, maar dit is wat ik zo kan verzinnen. Maar je hebt gelijk, er is ook aardig wat overlap. Ze zijn dan ook beide gebaseerd op het LINDA model.