Problem with UDP

[pjot]

BUT: it seems that the original net-receive-udp timeout does not work anymore.



(net-receive-udp 57000 128 50000 "127.0.0.1")



If I use this string in the newLisp prompt, newLisp waits endless. But it should timeout after 50000 microseconds. Using newlisp 8.1.0.

[HPW]

BUT: it seems that the original net-receive-udp timeout does not work anymore.

I see the same when testing with the newLISP.DLL on windows.

It seems not to get back when the timeout is over.

Instead it makes the timeout when it get's a UDP-message.

Then it makes the pending timeout.

[Lutz]

I am not in the office right now but will check later this evening. There have been some changes in UDP stuff, but 8.10 is identical to 8.1.0-rc2 in this respect.



Lutz

[Lutz]

I found the problem, the feature got wiped out doing the other UDP additions. I will do a re-release on Friday with version 8.1.1



Lutz



PS: this will not contain the new install_home options, I want to go safe because of changes in newlisp-tk.tcl.

[nigelbrown]

Lutz,

Would you like to e-mail me the home_install makefiles and newlisp-tk.config.home to try out? I have a few live distros.

Regards

Nigel

[Lutz]

If you could test that the new install features on a few live distros, that would be great!



I have all your stuff integrated but did not want to risk anything for 8.1.1. There is also a small change in newlisp-tk.tcl, which I did not want to have exposed for this release. I have had too much trouble with directory and startup issues in newlisp-tk in the past.



I just put 8.1.1 with the UDP timeout fix in the development directory and want to put this in the release directory tomorrow.



I will do a 8.1.2 development release shortly after with the new make file features for the $HOME install.



Lutz

[nigelbrown]

I'll look out for it Lutz



Maybe you should consider using the even=stable odd=devel system

for the minor version number a la kernal etc

with 8.2 the next stable release and 8.2.1 etc bug fixes

and 8.3.z the devel series - or maybe that's going too far for newlisp?

It would more clearly split off the new testing stuff.

Nigel

[pjot]

Hi Lutz, I see your new 8.1.1 version, I will test it this evening.



Thanx,



Peter

[HPW]

8.1.1 works for me with the DLL-version.

[pjot]

Yes, the timeout works OK again. Thanks!

[newdep]

Hello Lutz,



Actualy i ran into the fact that a (net-receive-udp) is the only option

under linux to receive a broadcast message. Where on windows also

a (net-listen...) (net-receive-from) works on receiving boradcasts....??

Could this be correct?



Regards, Norman/

[Lutz]

the underlying 'C' code is the same on both OS, but there seem to be differences how both OS implement the socket stack. I also observed, that on some OS the broadcast flag is unnecessary and just sending to the broadcast address is enough.



Lutz

[pjot]

Hi all,



Just to let you know, I created a simple UDP chat using GTK. Though fully functional, it's more like an advanced demonstration. Screenshots can be found here:



http://www.gtk-server.org/apps.html">http://www.gtk-server.org/apps.html



The full source can be downloaded there as well.



--------------------



Features:



- Full GTK2.x

- Using scrolled text_view widget

- Memorizes last entered configuration

- Works on Linux and Win32 with same source code

- Uses encryption of the actual chat



Bugs, remarks, comments are welcome.



Peter.

[Lutz]

Thanks Peter, looks great! When I start chat.lsp it starts the gtk-server creates the main window and outlines the controls but then seems to wait for something. Is there a server application I have to start first?



Lutz

[pjot]

No, the chatprogram is server and client at the same time!



So, when somebody sends a UDP DGRAM to your IP address, it will be displayed by the chat program.



You have to specify the IP address in the upper entry, with a port. (If you do not specify a port, the default port 54000 is used.)



The IP address specifies the remote host, where you send your chat (DGRAM) to. The specified port however is BOTH the remote port AND ALSO the local port, where the chat program listens for incoming DGRAMS. So the port number should be the same on both sides, as well as the encryption string.



I hope you enjoy the chat!