Archived
Problems transmitting a long variable between JavaScript and C#
Hello,
we are trying to connect to one of our C# service from a JavaScript implementation via WS. Everything works fine, but one paramter value is lost in the transmission. We have a class TimeSpanDto which has one parameter Ticks. This has the data type "long".
Every time we insert Ticks in this class on the JavaScript side we see them passed down to Ice stream.
But on our service side (C#) there arrives only a 0 in the Ticks of our TimeSpanDto parameter.
We are using currently 3.6.2 for the implementation of C# and for the slice2JS compiler.
Is there a known issue in the old version which is preventing us from transmitting this datatype?
Or is it a problem of the encapsulated long parameter in a custom class?
Cheers
Aikson
["clr:property"]
class TimeSpanDto {
long \Ticks;
};
Comments
-
Hi Aikson,
how are you initializing the value in JavaScript, long types must use Ice.Long class see https://doc.zeroc.com/ice/3.6/language-mappings/javascript-mapping/client-side-slice-to-javascript-mapping/javascript-mapping-for-built-in-types
0 -
Hello Aikson,
["clr:property"] class TimeSpanDto { long \Ticks; };While the backslash before
Ticksis correct, it should not be necessary, sinceTicksis not a Slice keyword. See:
https://doc.zeroc.com/ice/3.7/the-slice-language/lexical-rules#id-.LexicalRulesv3.7-KeywordsCheers,
Bernard0 -
Hello Jose,
thanks for the help. I read the documentation before, but I was unsure what it means. But now we hopefully have figured it out. Was a little complicated to get the Ice.Long to our TypeScript code.
A little follow up question for the WS endpoints. If we are not specifying a port, a random port is used. For our tcp endpoints this ports are normally in the "Ephemeral" port range. But we discovered that the WS endpoints getting port much lower to that range. Is this a build in feature, so WS always has lower ports? And if so, which range would it be, if we are not specifying things.
Cheers
Aikson0 -
Hi,
You should consider moving to 3.7 that has TypeScript support, see Ice.Long definition https://github.com/zeroc-ice/ice/blob/3.7/js/src/Ice/Long.d.ts
We also improve Ice.Long constructor to allow creating Ice.Long instance from JS Number, https://github.com/zeroc-ice/ice/blob/3.7/js/src/Ice/Long.js#L13-L21
Regarding "Ephemeral" port range both should use the same, they both are using the same underlying tcp acceptor, are you observe this different ranges in the same machine?
0 -
Hello,
@bernard: Yes we could remove the backslash, but we are code generating the ice files for our DTOs from our Models and therefore we escape all parameter names to be sure
@xdm: You were right, I checked other services with tcp ports on this machine and they are also coming up with the "wrong" port range. I now checked the windows settings and these are strangely different on this machine, maybe it was an update or something else switched them around.
For documentation purpose.
You could use following calls to display the current port range.C:\>netsh int ipv4 show dynamicport tcp Protocol tcp Dynamic Port Range --------------------------------- Start Port : 1025 Number of Ports : 64510
And this call to set it to the "default" one of MS since Server 2008
C:\>netsh int ipv4 set dynamicport tcp start=49152 num=16384
We know that you extended the TypeScript support in 3.7.1, but right now we have difficulties to process our slice files in the new slice2xx programs. We dealt with the forward declaration in our slice files, which you changed in the 3.7 release and now we must figure out what to do to get our stuff working again.
Cheers
Aikson0
