Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Problem: Talking from Rebol to Rebol via socket

 [1/16] from: robert:muench:robertmuench at: 22-Feb-2009 8:55


-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hi, to track down my problem with the communication between my DLL and Rebol via sockets I tried to create a Rebol only example. Looks like it has the same problem. Here is my code (much simpler than the DLL code): === Server rebol [] c-port: 12345 listen: open join tcp://: c-port waitports: [listen] print "Listening:" forever [ ; wait until something happens connection: wait waitports if same? connection listen [ print [tab "Connected"] print [tab "Read message from c-side"] c-client: first connection wait c-client print copy c-client print [tab "Send answer to c-side"] insert connection "r-side" print [tab "Closing socket"] close connection ] ] === Client rebol [] connection: open tcp://localhost:12345 insert connection "r-side-client" while [data: copy connection] [prin data] print close connection halt === Program outputs - --- Server Listening: Connected Read message from c-side ** Access Error: Network timeout ** Where: forever ** Near: print copy c-client print [tab "Send answer to c-side"]
>>
- --- Client ** Access Error: Network timeout ** Where: include-script ** Near: data: copy connection
>>
=== Idea & Problem I want to first send a short message from client to server and than receive an answer from the server side. I think I'm somehow missing either - - an "end" marker for the messages or - - a way to tell that the message is "complete" or - - a way to specify how long the message will be I'm sure the fix is quite simple but... I don't get it :-). Any feedback is welcome. Robert -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: iso-8859-15 wsBVAwUBSaEFDnSQa/BbHGLwAQlSsAf/Uya52MvcoV7+I6X/n79ToKBb8CtMGUOv jwSO11P4+cYrKAY+3rjJtQgSUlrz4newJCzZOsysojQlO4LowUSw4sXgmeR4C8VV Dr74N/WFf0Bo40B+80tLpJTkNaTccm8Okf+USVFUIFBkpqJUWTlLf3pN5GAjgIWj vBwJqNkC6NFhVGBr95lCdjRZjhKj3LWVcQPTQvPIooZUPDt2sIiFRf6OApVYnsQr GcUhLZoRbadw3ss49r9kY1fIcyJ6iUU0SZ9/9Fmtoaezxk4kqMNgDPxzBufhdLd9 2gLBV6coxhrGjKIfBkKyCl2jgk4iQxspEYQ6X6/wsSBjAJT7eMjO9g== =kX/q -----END PGP SIGNATURE-----

 [2/16] from: santilli:gabriele:gmai:l at: 22-Feb-2009 11:45


[Also sent privately because often Ecartis mangles my emails. Feel free to forward to the ML if this does not get there.] On Sun, Feb 22, 2009 at 8:55 AM, Robert M. M=C3=BCnch <robert.muench-robertmuench.de> wrote:
> c-client: first connection > wait c-client > print copy c-client > > print [tab "Send answer to c-side"] > insert connection "r-side"
The port is c-client not connection (which is the listen port).
> print [tab "Closing socket"] > close connection
Same error here. HTH, Gabriele.

 [3/16] from: petr:krenzelok:seznam:cz at: 22-Feb-2009 11:51


Robert M. Münch napsal(a):
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384
<<quoted lines omitted: 18>>
> print [tab "Send answer to c-side"] > insert connection "r-side"
;------------------- Bug here - it should be - insert c-client. You can't insert into listening socket, just to derived connection channel. But - your script will not even get here. You use blocking synchronous communication. In this mode, it seems to me, that you stay stuck in the 'copy section, untill you close the connection on the other side. Hopefully it could be proved by checking the WireShark ... I don't use any other mode than open/direct/no-wait .... you have to be just carefull here - you need to "wait", or the program runs out ... In your while look, when reading out the data, you can receive empty result = no data, or none = other side closed the connection .... If you want better multiplexing, it would be probably better to build wait block, along with time interval, so you either get your processing by an event received from network, or time timeout .... Here's small examples: client: open/direct/no-wait tcp://localhost:9005 data: read %user.r forever [ print "Sending data" insert client data wait 5 ] ---------------------------- server: open/direct/no-wait tcp://:9005 conn: first wait server print "Got connection ..." forever [ wait conn while [not empty? data: copy conn][print ["Read: " length? data]] ] -pekr-

 [4/16] from: robert:muench:robertmuench at: 22-Feb-2009 14:14


-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Am 22.02.2009, 11:45 Uhr, schrieb Gabriele Santilli <santilli.gabriele-gmail.com>:
> On Sun, Feb 22, 2009 at 8:55 AM, Robert M. M=FCnch > <robert.muench-robertmuench.de> wrote:
<<quoted lines omitted: 8>>
>> close connection > Same error here.
Hi, ok, thanks. Could it be that some docs/examples are wrong? I thought I have looked this up but anyway. Nevertheless, still the same problem with timeouts. - -- Robert M. M=FCnch Management and IT freelancer http://www.robertmuench.de -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: iso-8859-15 wsBVAwUBSaFPu3SQa/BbHGLwAQmxuAf/cCibxFvX3VDlMYLs2t1fhUCWXEt/u2ul yNH8kKs5t5EO3tECwfkFw9ggMKonAmhPGn2Dx7e+IN9DpMdpfZKP0LgoTLRuzwhZ 2M4Pud6QoGtMutvhVpxj4U1snukFhrImT3I0mMFMU6bSOG/Xdt9RE6pSSQhDfDTx 1Z/VD/Zu2QS98+BgBALSNrY4QEix2pi/k00uesizUenDnjpr1lxN7HinxerryIsM cM97RIJ3ePrBEC2shaBsJm4Jk8JjWQ/it/5yuOtihPY8DkZnv0UF4zPlxy7hpMUv mgqGOnT2asKewbna6aHzBwXMZcO2hM9xLMG+pxDLXRfBF4eZgjEukg== =vHRZ -----END PGP SIGNATURE-----

 [5/16] from: robert::muench::robertmuench::de at: 22-Feb-2009 14:26


-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Am 22.02.2009, 11:51 Uhr, schrieb Petr Krenzelok <petr.krenzelok-seznam.cz>:
> Bug here - it should be - insert c-client. You can't insert into > listening socket, just to derived connection channel.
Hi, ok, I got this now :-).
> But - your script > will not even get here. You use blocking synchronous communication. In > this mode, it seems to me, that you stay stuck in the 'copy section, > until you close the connection on the other side.
Good point and is something I observed too. But it's not documented when using synchronous mode how to get things transferred. So the listening part hangs until the other side closes the socket, than the so far received content is returned. This means, that using synchronous mode isn't feasible to send messages back and forth over the same socket.
> I don't use any other mode than open/direct/no-wait .... you have to be > just carefull here - you need to "wait", or the program runs out ...
Ok, thanks. While scanning some other Rebol scripts I saw this sometimes. But again, the docs are a bit simple on all this. I expect this to be the same problem in my other post. Because Rebol uses the synchronous mode, I just can't swap directions. I will look into this /direct/no-wait stuff.
> In your while look, when reading out the data, you can receive empty result > = no data, or none = other side closed the connection ....
Ok, that maps to socket behavior on the C level. Makes sense.
> If you want better multiplexing, it would be probably better to build wait block, > along with time interval, so you either get your processing by an event > received from network, or time timeout ....
Yes, whereas my goal is to just send messages back and forth using the same socket/connection.
> Here's small examples: > ...
Thanks, this brings me a step forward. - -- Robert M. M=FCnch Management and IT freelancer http://www.robertmuench.de -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: iso-8859-15 wsBVAwUBSaFSjHSQa/BbHGLwAQnaHAgAnGm/ycSuJ7zo41EW7s7EiX7mtiIYYsC1 8kk+yN2lymK7S3n7Fdtp2gWL9Xxe3filMxrmlkej3TeiM7gDZBcySxitb2GW73XS 83aS6QWExqDnmqjjQac7un3cRB+xLps+Ae8nPhTEtmR0t/bYPVSzTL5tHzie0PcL Bk86bfJ1TBs2Bp6lc7tnwVaSPObVOoZK8MpcphZC3KXJJBe6TcHw/FrS2DEB4xgR uR4cewn+WDO9UnTB/mpm3OwZfA+naVW2/5b382s6QMJlJHHop12iHGzmuApQWYm9 OOaJg7GsnLr7fyORVGnNZbdGVsb9suVpoqAN3P5NtYOh+vdW2lu0Iw== =q1Ed -----END PGP SIGNATURE-----

 [6/16] from: robert:muench:robertmuench at: 22-Feb-2009 14:50


-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hi, I made some small steps forward. At least I can send a message and get an answer. But only once, I want this to run in a loop on the server and the client side. My actual code now is: === Server rebol [] c-port: 12345 listen: open/direct/no-wait join tcp://: c-port waitports: [listen] print "Listening:" ; wait until something happens connection: wait waitports if same? connection listen [ print [tab "Connected"] c-client: first connection forever [ print [tab "Read message from c-side"] print copy c-client print [tab "Send answer to c-side"] insert c-client "r-side" ] ] === Client rebol [] connection: open/direct/no-wait tcp://localhost:12345 forever [ print "Sending to Rebol server" insert connection "r-side-client" print "Receiving from Rebol server" prin tab while [data: copy connection] [prin data] print newline ] === Problem The client side can only send once because it get stuck in the WHILE loop always getting some data from the server. The server loops, doesn't read anything from the client and immediately sends out the next message to the client. Is there a way that I can WAIT to "read a message" or "send a message"? I'm missing a way to control/react on the communication direction flow. - -- Robert M. M=FCnch Management and IT freelancer http://www.robertmuench.de -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: iso-8859-15 wsBVAwUBSaFYJnSQa/BbHGLwAQnnwQf6AmlifawzCwI7bKXPXpXvGeCoac0L2DJC VlA5+BNzwCg/OXjFkD07mN+WDV6yM2zXDWy/HzaK6IPyz3GHmdw/DVU29kp6RqE+ zcn7nRwXPx3edfRbet4lWlBoU4HrHGMsZDTPSSBf0+y1s6chSaLuzGVrnF2hsVgd REHUhKHlUDA234CWtJaoNXLpHqdXtN+adkRXu0BuPJ92QyKDifQ7/dPU4GRBKGQ9 AQBnBfRmvlPTQZAJfWETP2xX+4uFMhx4jfxpNVKGCIrebWIdqCaq6e3OXBeRSAPS zyr7GmJLeNQD1mxeHkOMFEReG75Hy2JsUtpU7ogfRgPj3Iqn7N9jIA== =owqz -----END PGP SIGNATURE-----

 [7/16] from: petr::krenzelok::seznam::cz at: 22-Feb-2009 15:40


Robert M. Münch napsal(a):
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384
<<quoted lines omitted: 37>>
> Is there a way that I can WAIT to "read a message" or "send a message"? I'm > missing a way to control/react on the communication direction flow.
yes, there is. In async mode, you are responsible for "waiting for signal" - you have to do handshaking yourself. As I said in my previous email, be carefull, as you will run out from your data :-) So, look into your server. You waint for first connection. Good. Then you get your connection, enter forever loop, but you don't wait for the other side! Copy is not blocking, so it copies from the OS buffer (direct mode), and there is no data (empty string returned). Put wait c-client as first means of forever loop. The mindset is more difficult with async mode, and I sometimes too struggly a bit - where to wait, and where the wait is not necessary. Here's the mindset: wait port ; or wait/all [port1 port2 0:00:01], whatever ... while [not empty? data: copy port][append result data] remember, that one call to 'copy just reads out what is available at the given time. Sometimes ppl use copy/part, to read in some chunks. while not empty? will ensure you read out everything available. But you don't have to do that, as you can as well read it out "at next port visit" :-) If you want to look how to read data from many ports, Sterling's proxy script in rebol.org archive was always a good inspiration for me, as it was able to open multiple connections, keep pairs of send/rcv ports stored, etc. Robert- here's my "multiserver" script I did for my friend some time ago. He was doing some embedded stuff and wanted me to catch data from devices, write them down to file, and log events. Not sure it will work for you, as I now translated it into english, including variables. Hopefully no bug there: ---------------------------- REBOL [ Title: "Multiserver" Version: 0.2 Author: "Petr Krenzelok" ] ;--- open listen server in an async mode listen-port: 9005 server: open/direct/no-wait/binary join tcp://: listen-port print ["Server running on port: " listen-port] ;--- set-up a wait-list - rebol will wait for every item contained ... wait-list: copy [] ;--- set-up a block to store open connections in there ... ;--- along with info - remote IP, port ... conn-list: copy [] ;--- insert time and server into wait-list insert wait-list 0.001 insert wait-list server ;--- forever= endless loop .... forever [ event-port: wait wait-list ;--- if more events, let's pick first one (maybe not needed?) if block? event-port [event-port: first event-port] ;--- has event happened on our listening server? (new connection request) ;--- if so, accept the connection, insert connection into wait-list if event-port == server [ ;--- accept connection ... time: now/time/precise connection: first server print join "New connection from: " [connection/remote-ip ":" connection/remote-port " at " time] ;--- append it into list of ports we wait for events (wait-list) insert wait-list connection ;--- append into our internal register of connections and its parameters insert conn-list reduce [connection connection/remote-ip connection/remote-port] write/append join %data- reduce [connection/remote-ip "-" connection/remote-port".txt"] join "New connection from: " [ connection/remote-ip ":" connection/remote-port " at " time newline "---------------------------------------------------------" newline ] ;--- uncomment to see the data in console ... ;probe connection ] ;--- if event received is not new connection, it might be data on already existing connection if found? conn-port: find conn-list event-port [ ;--- let's copy data ... time: now/time/precise data: copy event-port ;--- close request (none) or real data arriving? either none? data [ print join "Closing connection request from: " [conn-port/2 ":" conn-port/3 " at " time] ;--- Write close even request into file ... write/append join %data- reduce [conn-port/2 "-" conn-port/3 ".txt"] join newline [ "---------------------------------------------------------" newline "Closing connection request from: " conn-port/2 ":" conn-port/3 " at " time newline newline "=========================================================" newline newline ] close event-port remove/part conn-port 3 ][ ;--- if we are here, real data arrived ... print join "Data from: " [conn-port/2 ":" conn-port/3 " at " time] ;--- write data into file ... write/append join %data- reduce [conn-port/2 "-" conn-port/3 .txt ] to-string data ;--- uncomment to see data printed to console ;print mold to-string data ;print mold data ; data as binary, not string ] ;end 'either ] ;end 'if ] ;end 'forever

 [8/16] from: robert::muench::robertmuench::de at: 23-Feb-2009 9:45


Am 22.02.2009, 15:40 Uhr, schrieb Petr Krenzelok <petr.krenzelok-seznam.cz>:
>> Is there a way that I can WAIT to "read a message" or "send a message"? >> I'm missing a way to control/react on the communication direction flow.
Hi, (why are my lines broken with this = char? Is it again a encoding problem from Opera?)
> yes, there is. In async mode, you are responsible for "waiting for > signal" - you have to do handshaking yourself.
No problem, is there an example? Do I get signals like "ready to send", data can be read ?
> As I said in my previous > email, be carefull, as you will run out from your data :-)
That's normal TCP behaviour. On the C-level I can loop and check read/write Status, read partial things etc. The problem I have is, that I don't know how Rebol handles these situations nor how I'm supposed to do it.
> So, look into your server. You wait for first connection. Good. Then you > get your > connection, enter forever loop, but you don't wait for the other side!
Ok, how do I wait for the other side? Is just adding a WAIT CONNECTION enough?
> Copy is not blocking, so it copies from the OS buffer (direct mode), and > there is no data (empty string returned). Put wait c-client as first > means of forever loop.
Ok, the WAIT read: Wait until something is available in the OS read-buffer.
> wait port ; or wait/all [port1 port2 0:00:01], whatever ... > while [not empty? data: copy port][append result data] > > remember, that one call to 'copy just reads out what is available at the > given time.
Yes, I know. I will try playing with WAIT.
> If you want to look how to read data from many ports, Sterling's proxy > script in rebol.org archive was always a good inspiration for me, as it > was able to open multiple connections, keep pairs of send/rcv ports > stored, etc.
Most scripts assume a request/response model or use the HTTP schemes. What I want to do is: Using one port for sending and receiving while doing ping-pong between two clients.
> Robert- here's my "multiserver" script I did for my friend some time > ago. He was doing some embedded stuff and wanted me to catch data from > devices, write them down to file, and log events. Not sure it will work > for you, as I now translated it into english, including variables. > Hopefully no bug there:
Ok, thanks I take a look. Handling transmission in only one direction is not the problem. It's switchting between receiving and sending and getting the WAITing etc. correct. So, next round :-) I'll let you know. If someone has more information or an exmaple, please let me know. -- Robert M. Münch Mobile: +49 (177) 245 2802 http://www.robertmuench.de

 [9/16] from: sqlab:gmx at: 23-Feb-2009 11:31


Here is your example with some minor changes, that should work. rebol [] c-port: 12345 listen: open/no-wait join tcp://: c-port waitports: [listen] print "Listening:" forever [ ; wait until something happens either same? listen connection: wait waitports [ print [tab "Connected"] c-client: first connection append waitports c-client ] [ print [tab "Read message from c-side"] print copy connection print [tab "Send answer to c-side"] insert connection "r-side" print [tab "Closing socket"] close connection ] ] rebol [] connection: open/no-wait tcp://localhost:12345 insert connection "r-side-client" while [data: copy connection] [probe data] close connection halt Robert M. Münch wrote:

 [10/16] from: petr:krenzelok:seznam:cz at: 23-Feb-2009 11:50


Robert M. Münch napsal(a):
> Am 22.02.2009, 15:40 Uhr, schrieb Petr Krenzelok > <petr.krenzelok-seznam.cz>:
<<quoted lines omitted: 3>>
> Hi, (why are my lines broken with this = char? Is it again a encoding > problem from Opera?)
I can see your replies just OK.
>> yes, there is. In async mode, you are responsible for "waiting for >> signal" - you have to do handshaking yourself. >> > > No problem, is there an example? Do I get signals like "ready to send", > "data can be read"? >
Ah, I meant nothing like that, just simple usage of wait, read-outs and sending of data. But maybe some gurus here know more about internal TCP port states (flags). Generally imo there should be absolutly no problem in using both directions, as TCP communication uses TCP buffers (64KB on recent systems), so REBOL should be fast enough to read data out from the ports ...
>> As I said in my previous >> email, be carefull, as you will run out from your data :-)
<<quoted lines omitted: 3>>
> don't know how Rebol handles these situations nor how I'm supposed to do > it.
I might try to adapt my example to some simple usage case scenario. E.g. server on one side, 10 clients (10 ports) on other side, reading random .r files in directory, sending them forth and back, asynchronously, but I can see sqlab posted some example already. There are some docs on the net (I found even one describing open/direc/async from some alpha 2.5.5 Core, but that was later deprecated), you might look along the lines of Romano's atcp:// protocol, and IIRC Gabriele and guys did something for the Network Detective project? ( http://www.colellachiara.com/soft/Libs/async-protocol.r )
>> So, look into your server. You wait for first connection. Good. Then you >> get your >> connection, enter forever loop, but you don't wait for the other side! >> > > Ok, how do I wait for the other side? Is just adding a WAIT CONNECTION > enough? >
I think so ...
> So, next round :-) I'll let you know. If someone has more information or > an exmaple, please let me know. >
It would be good, if we could move to R3 for such stuff, but we will have to wait few more months :-) -pekr-

 [11/16] from: robert:muench:robertmuench at: 23-Feb-2009 12:43


Am 23.02.2009, 11:31 Uhr, schrieb sqlab <sqlab-gmx.net>:
> Here is your example with some minor changes, that should work.
Hi, some more questions: 1. The client now uses active polling. Is there a way to let it WAIT until something is there? 2. How to send messages back and forth in a loop without closing the socket? 3. This here is one round-trip that only works if the socket is closed. Not closing the socket won't send the answer to the client. Instead the client loops forever. -- Robert M. Münch Mobile: +49 (177) 245 2802 http://www.robertmuench.de

 [12/16] from: sqlab:gmx at: 23-Feb-2009 13:00


ok, the same example with waiting for events and ping pong messages in a 10 sec forever intervall. This you can do with many sockets too, but then it is more elegant to use awake finctions. rebol [] c-port: 12345 listen: open/no-wait join tcp://: c-port waitports: [listen] print "Listening:" forever [ ; wait until something happens either same? listen connection: wait waitports [ print [tab "Connected"] c-client: first connection append waitports c-client ] [ print [tab "Read message from c-side"] msg: copy connection either not msg [ print [tab "Closing socket"] close connection ] [ print msg print [tab "Send answer to c-side"] insert connection "r-side" ] ] ] rebol [] connection: open/no-wait tcp://localhost:12345 forever [ insert connection "r-side-client" wait connection probe copy connection wait 10 ] Robert M. Münch wrote:

 [13/16] from: robert:muench:robertmuench at: 23-Feb-2009 13:36


Am 23.02.2009, 13:00 Uhr, schrieb sqlab <sqlab-gmx.net>:
> ok, the same example > with waiting for events and ping pong messages in a 10 sec forever > intervall.
Hi, thanks this now works. Great! :-) So the only change was on the client using a WAIT.
> This you can do with many sockets too, but then it is more elegant to > use awake finctions.
Yes, it just want to start simple :-) Some questions regarding time-outs etc. 1. If I make a connection from the client but don't send anything. Will a timeout happen on the server side? Where can I get/set this timeout value? 2. What about send/recv timeouts? Can I get/set these as well? Are these different than the timeout of 1. (if any at all)? Thanks. -- Robert M. Münch Mobile: +49 (177) 245 2802 http://www.robertmuench.de

 [14/16] from: semseddinm:bircom at: 23-Feb-2009 14:56


Hi, there is an example use of changing the default timeout value of network ports, on rebol.org, script named GISMO by Carl.

 [15/16] from: petr:krenzelok:seznam:cz at: 23-Feb-2009 15:31


Robert M. Münch napsal(a):
> Am 23.02.2009, 13:00 Uhr, schrieb sqlab <sqlab-gmx.net>: >> ok, the same example
<<quoted lines omitted: 3>>
> Hi, thanks this now works. Great! :-) > So the only change was on the client using a WAIT.
Yes, it could be said so.
>> This you can do with many sockets too, but then it is more elegant to >> use awake finctions.
<<quoted lines omitted: 3>>
> 1. If I make a connection from the client but don't send anything. Will a > timeout happen on the server side? Where can I get/set this timeout value?
When you make a connection, timeout happens on listening socket (tcp://:12345). Each port has port/timeout value. For tcp ports, it is by default set to 30sec. You can change the value, if you want. Reading dns can be made async too. The only thing, we can't have async in R2 is if the other side is not responding to connection request (e.g. listening server not available, server down, etc.). The only thing you can do is to just - wait for timeout on port trying to make a connection. IMO 30sec. default timeout is nonsense nowadays, I would lower it to 5 or 10 secs. But - apart from that, you are pretty much async even with R2. What I am not clear about is R2's 'wait function. When you e.g. do something following: 1) wait [server client1 client2 client3 timer] 'wait returns first port with event. You react to event, OK. At next loop (wait) iteration, it return first port with event too. But what if there is new event on the same port? Will other ports be handled? Or will first port in block has some logical precedence? note: the timer above DOES NOT mean, that you get your processing at the defined timer tick! It just means - either we get an event on one of ports, or we get a timeout on timer. 2) wait/all [server client1 client2 client3 timer] you receive a block with all event ports. You then have to loop over it, to serve those ports. Maybe this is better option that the first one? (albeit the event processing loop will be a bit more complicated) -pekr-

 [16/16] from: sqlab::gmx::net at: 23-Feb-2009 15:54


Robert M. Münch wrote:
> Am 23.02.2009, 13:00 Uhr, schrieb sqlab <sqlab-gmx.net>: > >> ok, the same example >> with waiting for events and ping pong messages in a 10 sec forever >> intervall. >> > > Hi, thanks this now works. Great! :-) >
You are welcome
> So the only change was on the client using a WAIT. > >> This you can do with many sockets too, but then it is more elegant to >> use awake finctions. >> >
functions not finc..
> Yes, it just want to start simple :-) > > Some questions regarding time-outs etc. > > 1. If I make a connection from the client but don't send anything. Will a > timeout happen on the server side? Where can I get/set this timeout value? >
No, you will not get a timeout. You are using no-wait ports. If you copy from this kind of ports, you will either get none -> socket is closed by the peer, better close it too -> you are reading without data waiting, better read only after you get an event, showing that something has arrived your message -> speaks for itself Take care that you can get your message in parts.
> 2. What about send/recv timeouts? Can I get/set these as well? Are these > different than the timeout of 1. (if any at all)? >
This you have to handle by yourself. One way to do could be Keep the time of the last event for each socket, Define a timeout action, where you compare the actual time with the last event time and act accordingly maybe like this; ------------ append connectionlist timeout either port: wait connectionlist [ act-on-port port ] [ foreach port connectionlist [check-an-act port] ]

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted