RemoteEndpoint.sendString + ByteBuffer / bytes[]

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

RemoteEndpoint.sendString + ByteBuffer / bytes[]

Edgar Espina
Hi,

 I need a sendString method on RemoteEndpoint that accepts a ByteBuffer/bytes[] as parameter, not just a String.

 I do have a JSON library that generates byte[] and today I have to wrap it as String to send a text message over the web socket.

 Not a big deal, but it will be nice to have.

Thanks


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: RemoteEndpoint.sendString + ByteBuffer / bytes[]

Joakim Erdfelt-8
Sending raw bytes on the WebSocket remote might not make sense.

The RFC6455 mandates that messages consisting of TEXT (+ optional CONTINUATION) frames must be UTF-8 encoded.
We enforce that part of the spec simply by making sendString(String) the defined approach.

Using ByteBuffer or byte[] would be an attempt to send something that is without a declared encoding.
If we had a sendString(ByteBuffer) then we would have to convert to a String with UTF-8 encoding ourselves, at which point the send might fail due to a violation of the RFC for WebSocket.
Its easier to have this UTF8 conversion before the jetty implementation so that you can handle the UTF8 conversion in your own way (eg: do you fail? do you replace invalid sequences? if so, with what? do you drop failed sequences?)



--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 5:57 AM, Edgar Espina <[hidden email]> wrote:
Hi,

 I need a sendString method on RemoteEndpoint that accepts a ByteBuffer/bytes[] as parameter, not just a String.

 I do have a JSON library that generates byte[] and today I have to wrap it as String to send a text message over the web socket.

 Not a big deal, but it will be nice to have.

Thanks


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: RemoteEndpoint.sendString + ByteBuffer / bytes[]

Edgar Espina
Yes, I know. What I'm looking for is something like:

RemoteEndpoint.sendText(ByteBuffer/bytes, Callback)

where the buffer/bytes is/are already in UTF-8.

Thank you, Joakim.


On Mon, May 18, 2015 at 4:17 PM Joakim Erdfelt <[hidden email]> wrote:
Sending raw bytes on the WebSocket remote might not make sense.

The RFC6455 mandates that messages consisting of TEXT (+ optional CONTINUATION) frames must be UTF-8 encoded.
We enforce that part of the spec simply by making sendString(String) the defined approach.

Using ByteBuffer or byte[] would be an attempt to send something that is without a declared encoding.
If we had a sendString(ByteBuffer) then we would have to convert to a String with UTF-8 encoding ourselves, at which point the send might fail due to a violation of the RFC for WebSocket.
Its easier to have this UTF8 conversion before the jetty implementation so that you can handle the UTF8 conversion in your own way (eg: do you fail? do you replace invalid sequences? if so, with what? do you drop failed sequences?)



--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 5:57 AM, Edgar Espina <[hidden email]> wrote:
Hi,

 I need a sendString method on RemoteEndpoint that accepts a ByteBuffer/bytes[] as parameter, not just a String.

 I do have a JSON library that generates byte[] and today I have to wrap it as String to send a text message over the web socket.

 Not a big deal, but it will be nice to have.

Thanks


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: RemoteEndpoint.sendString + ByteBuffer / bytes[]

Joakim Erdfelt-8
The interface would have to be ...

RemoteEndpoint.sendText(ByteBuffer, Utf8Mode, WriteCallback)

Still not sure this makes sense as a specialized/convenience method call.

--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 12:39 PM, Edgar Espina <[hidden email]> wrote:
Yes, I know. What I'm looking for is something like:

RemoteEndpoint.sendText(ByteBuffer/bytes, Callback)

where the buffer/bytes is/are already in UTF-8.

Thank you, Joakim.


On Mon, May 18, 2015 at 4:17 PM Joakim Erdfelt <[hidden email]> wrote:
Sending raw bytes on the WebSocket remote might not make sense.

The RFC6455 mandates that messages consisting of TEXT (+ optional CONTINUATION) frames must be UTF-8 encoded.
We enforce that part of the spec simply by making sendString(String) the defined approach.

Using ByteBuffer or byte[] would be an attempt to send something that is without a declared encoding.
If we had a sendString(ByteBuffer) then we would have to convert to a String with UTF-8 encoding ourselves, at which point the send might fail due to a violation of the RFC for WebSocket.
Its easier to have this UTF8 conversion before the jetty implementation so that you can handle the UTF8 conversion in your own way (eg: do you fail? do you replace invalid sequences? if so, with what? do you drop failed sequences?)



--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 5:57 AM, Edgar Espina <[hidden email]> wrote:
Hi,

 I need a sendString method on RemoteEndpoint that accepts a ByteBuffer/bytes[] as parameter, not just a String.

 I do have a JSON library that generates byte[] and today I have to wrap it as String to send a text message over the web socket.

 Not a big deal, but it will be nice to have.

Thanks


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: RemoteEndpoint.sendString + ByteBuffer / bytes[]

Edgar Espina
Okey,

My use case is a json library generating bytes[] in utf-8 and I can't change, so my ws need to send text (json) but source is a byte[].

Today, I wrap the bytes with new String(bytes, UTF-8) and then the TextFrame convert them again to a buffer:

setPayload(ByteBuffer.wrap(StringUtil.getUtf8Bytes(str)));

Isn't a huge deal but it will be a nice to have.


On Mon, May 18, 2015 at 4:48 PM Joakim Erdfelt <[hidden email]> wrote:
The interface would have to be ...

RemoteEndpoint.sendText(ByteBuffer, Utf8Mode, WriteCallback)

Still not sure this makes sense as a specialized/convenience method call.

--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 12:39 PM, Edgar Espina <[hidden email]> wrote:
Yes, I know. What I'm looking for is something like:

RemoteEndpoint.sendText(ByteBuffer/bytes, Callback)

where the buffer/bytes is/are already in UTF-8.

Thank you, Joakim.


On Mon, May 18, 2015 at 4:17 PM Joakim Erdfelt <[hidden email]> wrote:
Sending raw bytes on the WebSocket remote might not make sense.

The RFC6455 mandates that messages consisting of TEXT (+ optional CONTINUATION) frames must be UTF-8 encoded.
We enforce that part of the spec simply by making sendString(String) the defined approach.

Using ByteBuffer or byte[] would be an attempt to send something that is without a declared encoding.
If we had a sendString(ByteBuffer) then we would have to convert to a String with UTF-8 encoding ourselves, at which point the send might fail due to a violation of the RFC for WebSocket.
Its easier to have this UTF8 conversion before the jetty implementation so that you can handle the UTF8 conversion in your own way (eg: do you fail? do you replace invalid sequences? if so, with what? do you drop failed sequences?)



--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 5:57 AM, Edgar Espina <[hidden email]> wrote:
Hi,

 I need a sendString method on RemoteEndpoint that accepts a ByteBuffer/bytes[] as parameter, not just a String.

 I do have a JSON library that generates byte[] and today I have to wrap it as String to send a text message over the web socket.

 Not a big deal, but it will be nice to have.

Thanks


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: RemoteEndpoint.sendString + ByteBuffer / bytes[]

Joakim Erdfelt-8
Yup, lots of memory copying in that path.

But the need to "ensure" that the ByteBuffer is UTF8 encoded by the implementation will still occur.
Even with the alternate / proposed syntax, this copying will occur.

Also, the need to identify behavior for byte -> string conversion when encountering invalid UTF8 sequences would also need to be addressed in this proposed syntax. (something best done by the application)


--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 12:55 PM, Edgar Espina <[hidden email]> wrote:
Okey,

My use case is a json library generating bytes[] in utf-8 and I can't change, so my ws need to send text (json) but source is a byte[].

Today, I wrap the bytes with new String(bytes, UTF-8) and then the TextFrame convert them again to a buffer:

setPayload(ByteBuffer.wrap(StringUtil.getUtf8Bytes(str)));

Isn't a huge deal but it will be a nice to have.


On Mon, May 18, 2015 at 4:48 PM Joakim Erdfelt <[hidden email]> wrote:
The interface would have to be ...

RemoteEndpoint.sendText(ByteBuffer, Utf8Mode, WriteCallback)

Still not sure this makes sense as a specialized/convenience method call.

--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 12:39 PM, Edgar Espina <[hidden email]> wrote:
Yes, I know. What I'm looking for is something like:

RemoteEndpoint.sendText(ByteBuffer/bytes, Callback)

where the buffer/bytes is/are already in UTF-8.

Thank you, Joakim.


On Mon, May 18, 2015 at 4:17 PM Joakim Erdfelt <[hidden email]> wrote:
Sending raw bytes on the WebSocket remote might not make sense.

The RFC6455 mandates that messages consisting of TEXT (+ optional CONTINUATION) frames must be UTF-8 encoded.
We enforce that part of the spec simply by making sendString(String) the defined approach.

Using ByteBuffer or byte[] would be an attempt to send something that is without a declared encoding.
If we had a sendString(ByteBuffer) then we would have to convert to a String with UTF-8 encoding ourselves, at which point the send might fail due to a violation of the RFC for WebSocket.
Its easier to have this UTF8 conversion before the jetty implementation so that you can handle the UTF8 conversion in your own way (eg: do you fail? do you replace invalid sequences? if so, with what? do you drop failed sequences?)



--
Joakim Erdfelt <[hidden email]>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, May 18, 2015 at 5:57 AM, Edgar Espina <[hidden email]> wrote:
Hi,

 I need a sendString method on RemoteEndpoint that accepts a ByteBuffer/bytes[] as parameter, not just a String.

 I do have a JSON library that generates byte[] and today I have to wrap it as String to send a text message over the web socket.

 Not a big deal, but it will be nice to have.

Thanks


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: RemoteEndpoint.sendString + ByteBuffer / bytes[]

John Gardiner Myers
Throwing an IllegalArgumentException if the data are not valid UTF8 would seem to be sufficient. In the use case, the caller believes it is not possible for the data to have invalid UTF8 sequences.

On 5/18/2015 1:03 PM, Joakim Erdfelt wrote:
Yup, lots of memory copying in that path.

But the need to "ensure" that the ByteBuffer is UTF8 encoded by the implementation will still occur.
Even with the alternate / proposed syntax, this copying will occur.

Also, the need to identify behavior for byte -> string conversion when encountering invalid UTF8 sequences would also need to be addressed in this proposed syntax. (something best done by the application)



_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users