Freeplane Server

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

joetopshot
Hi Felix,

This is not my lucky day.  Looks like just about everyone has their Internet connection back except me .  So let me tell you what I've been doing and maybe you can figure out my problem.  I tried converting our REST code to websockets.  That turned out to be quite easy.

The problem I have is testing the code.  I downloaded a Chrome extension websocket client that I thought would prove very handy for testing (https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo?hl=en).  The problem I have is getting this client to work by picking the right URL.  Nothing seems to work.  So I went back to the sample program from Oracle (https://spring.io/guides/gs/messaging-stomp-websocket/#initial) and that works fine with the JavaScript client (just point to http://localhost:8080).

So now I know I have a good running websocket server (and a custom client) that all work.  I disconnected from that client and tried to use the Chrome extension websocket client.  That did not work.  I thought that ws://localhost/gs-guide-websocket would be the right URL.  What's worse is that I then went into Chrome developer tools and looked at the network traffic (looking at the custom URL).  That URL was ws://localhost:8080/gs-guide-websocket/757/qwtz0zka/websocket.  So I then tried copy/paste of that URL into the Chrome extension and it too did not work.  

So now I'm a little confused.  Any thoughts or ideas as to what I might have done wrong?  I'd be interested to see if you can get the client to work with that Oracle websocket program.

Be well,
Joe
--
Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Felix Natter
In reply to this post by joetopshot
hello team,

I just watched a good intorduction to WebSockets [in Spring]:
https://www.youtube.com/watch?v=MJeEAVJR2FA
Some points made:
- spring implements JSR-356
- made for many messages, collbaration!
- uses http for initial handshake
- supports text (utf-8) and binary messages
- messages are split into frames, but the order is not guaranteed,
  so we shall not use it
- jetty 7/8, tomcat 7, glassfish had their own, JSR-356-incompatible implementations
  (we're using tomcat (8?) so that should support JSR-356)
- WS Endpoints cannot be configured based on what's *in* the messages
  (i.e. choose a different endpoint base on message content)
- you map URIs to WebSocketHandlers
- the talk includes a testing-session with chrome
  (does that help a bit, Joe?)
- [I think] spring-JSR-356 can fall back to polling (old browser, behind proxies)
- discusses SocksJS, but IMHO that is not important for us at all
- a bit more...

There are more presentations explaining how to code JSR-356, like this
(I haven't watched this yet):
https://www.youtube.com/watch?v=nxakp15CACY

Cheers and Best Regards,
Felix
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Dimitry Polivaev
Administrator
> - messages are split into frames, but the order is not guaranteed,
>   so we shall not use it

Message fragments MUST be delivered to the recipient in the order sent
by the sender

https://stackoverflow.com/a/31894114

Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Felix Natter
hello Dimitry,

> Message fragments MUST be delivered to the recipient in the order sent
> by the sender

I may be totally wrong, but the SO post says that the order of of delivery is guaranteed because it uses TCP.
Does the fact that it's *on top of* TCP mean that the whole WS message (including all frames) is in *one*
tcp header?

Guessing here,
Felix
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Felix Natter
Sorry, I meant "in *one* segment"
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

joetopshot
In reply to this post by Felix Natter
Hi Felix,

Well, it took until this morning for me to get my Internet connection back up.  I did manage to work yesterday using 1.1 gb of my cell phone data plan.  I was surprised that the response time wasn't too bad.

I'm going to go through the youtube videos hopefully today or tomorrow.  I see the first one is 1 hr 16 min long.  I probably should have done that first but I do like playing around with new software.
--
Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

joetopshot
I have viewed the first Youtube video and started looking at the second one that Felix posted above.  Note that the first video is 3.5 years old (Jan 2014).  In the IT world, this is a looooong time ago.  The second video is from 2016 which is significantly better.  

From what I have heard, websockets is a technology that is really meant to be used in a realtime or semi-realtime environment where there are many and frequent exchanges of information between the client and the server. So my first question is whether this represents what we will be doing.  Dimitry, you would probably know better than anyone whether this is a valid and frequent use case.  I would have thought that updates between client and server would happen rather infrequently (once a minute, once every several minutes, once an hour, etc).  Am I wrong?  

According to the 2014 video, this technology is very new without much ancillary support.  One item I recall hearing (again, this was from the 2014 video) is that only UTF-8 and binary data are supported.  How do we handle foreign languages such as Hebrew and Chinese in that case? Another comment was that it does not work well with proxies.  But maybe these issues have been resolved in 2017.  

Nevertheless, it seems to me that the simple RESTful technology might again be the best way to communicate between client and server unless my assumption above is incorrect.  Thoughts?

--
Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Dimitry Polivaev
Administrator
Hello Joe,

Because we can not open a port on the client for delivering map update messages, we should not use REST protocol.
WebSockets seems to be the technology with the less protocol overhead, less problems with firewalls and bidirectional communication.

I thought we have already discussed it and decided to use it.

It is also perfectly documented and integrated in Spring making its use on the server side an easy play.

https://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html

However because I am not going to use Spring on the client side I would not use STOMP and use normal JSON objects for communication.

Regards,
Dimitry

On 19.07.2017 10:56, joetopshot [via Freeplane Developer] wrote:

> I have viewed the first Youtube video and started looking at the
> second one that Felix posted above.  Note that the first video is 3.5
> years old (Jan 2014).  In the IT world, this is a looooong time ago.
> The second video is from 2016 which is significantly better.
>
> From what I have heard, websockets is a technology that is really
> meant to be used in a realtime or semi-realtime environment where
> there are many and frequent exchanges of information between the
> client and the server. So my first question is whether this
> represents what we will be doing.  Dimitry, you would probably know
> better than anyone whether this is a valid and frequent use case.  I
> would have thought that updates between client and server would
> happen rather infrequently (once a minute, once every several
> minutes, once an hour, etc).  Am I wrong?
>
> According to the 2014 video, this technology is very new without much
> ancillary support.  One item I recall hearing (again, this was from
> the 2014 video) is that only UTF-8 and binary data are supported.
> How do we handle foreign languages such as Hebrew and Chinese in that
> case? Another comment was that it does not work well with proxies.
> But maybe these issues have been resolved in 2017.
>
> Nevertheless, it seems to me that the simple RESTful technology might
> again be the best way to communicate between client and server unless
> my assumption above is incorrect.  Thoughts?
>
> -- Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

joetopshot
Dimitry Polivaev wrote
Because we can not open a port on the client for delivering map update messages, we should not use REST protocol.
WebSockets seems to be the technology with the less protocol overhead, less problems with firewalls and bidirectional communication.

I thought we have already discussed it and decided to use it.

It is also perfectly documented and integrated in Spring making its use on the server side an easy play.

https://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html

However because I am not going to use Spring on the client side I would not use STOMP and use normal JSON objects for communication.
I know we discussed this but this was before I started playing with it.  There are ways around the issue of opening a port on the client side but I'll let that be.  I'll continue with websockets.

STOMP is a text-based protocol on top of websockets.  The kind of text you transmit is up to you so using STOMP and JSON together is fine as they are compatible with each other.
--
Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Dimitry Polivaev
Administrator
> I know we discussed this but this was before I started playing with
> it.  There are ways around the issue of opening a port on the client
> side but I'll let that be.  I'll continue with websockets.

If you have arguments against WebSockets and prefer other solutions feel free to share the arguments.

>
> STOMP is a text-based protocol on top of websockets.  The kind of
> text you transmit is up to you so using STOMP and JSON together is
> fine as they are compatible with each other

 
Maybe I see it wrong but currently I believe STOMP introduces an additional layer and I would need to explicitly support it on the client side.
I see no advantages of using STOMP on the top of JSON instead of just sending JSON objects.

Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

joetopshot
I had some fun today.  I converted our RESTful server to a websocket server. I also wrote a Java client that sends a simple POJO class to the server with some "content" (which you have to type in).  The server gets the message from the client, displays the results and returns a different POJO with the original info slightly modified.  The client then displays what it received from the server.

Note that I may have more time after this coming week to work on the code as my contract with my current client is not being renewed. While I will be actively looking for further employment, I will take this opportunity to further work on the server code.
--
Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Felix Natter
hi Joe,

glad that you've made so much progress! Unfortunately, I had to work for OpenText, had some personal stuff
and thus needed some rest (not REST ;-)).

In a few weeks I'll take 1-2 weeks off, so I'd like to work on the server too,
so leave over come work :-)

Cheers and Best Regards,
Felix

Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

joetopshot
I also found a rather interesting youtube video that is a little newer.  The speaker discusses an interesting app he put together that uses websockets and Spring 4.1.  it's a chat app that works with multiple people so that you can send a message and multiple people will be the recipients. Or you can send the message to only one person. There are some other clever aspects to his code.  The source code is on github at https://github.com/salmar/spring-websocket-chat but I do think it's worth watching the video.  URL is https://www.youtube.com/watch?v=oCAC2yow8xk.

--
Joe Berry
Reply | Threaded
Open this post in threaded view
|

Re: Freeplane Server

Felix Natter
hi Joe,

thanks for the link, I'll look at it.

Cheers and Best Regards,
Felix
12