hi, since we still use DA3 / Bin1 i guess it’s time to put some move away from plans in the works…
problem is that we need to do this without the need to reconfigure manually all installed sites
not only the move to DA4 / Bin2 needs to be facilitated but also getting new channels in place, the ones now still date from the beginning days of RO 
so in fact i need something that can switch channels / bin2 on the client side without the client needs to know about it
can this be done with (and i haven’t looked into it in detail) autodiscover/zeroconf?
tried to connect with regular channel to a supertcp server but that didn’t work (although i think it kinda should since they’re both tcp -just other functionality)
i guess it basically boils down to the client being able to configure itself based on the config of the server…
so how do i handle this the best and fail safe way
tia,
marc
Hi,
you can add a new custom port, say 9999, for communication with Bin2/DA4+.
as a result, if clients probes server for this port and server returns positive answer, client can communicate with server via this port.
another possibility is using ZeroConf/Bonjour. if some server is detected, client can get address:port from it and use it for communication via new protocol.
one disadvantage: Bonjour should be installed on all machines and it has some limitation, like it can detect servers only in local network.
ok so zeroconf isn’t an option…
but still, let’s say i want to use another channel, if the client isn’t aware of this new channel it can’t connect…
is there a roadmap which would ultimately handle this for me
so a universal client channel which instantiates behind the scenes the right one based on a server challenge?
at login, client should send to server information which data it waits (bin1 or bin2) so server will return data in needed format. as for me, it is pretty clean and transparent for user.
it can be easily added into LoginString
server will store this info in session. if this info isn’t specified, server will return data in old Bin1 format.
i want it the other way around… server is in control, but clients update themselves through RO update methods, so an old client needs to be able to connect to a new server and its the server who will decide on what channel / message to use… off course the client needs to be able to adapt, but that gives us a path to upgrade in a 2-phase way…
but for example, if i try to test what channel to use, and server is on supertcp, client on regular tcpchannel then i get an out of memory crash in the client… so the question is to have a base challenge protocol to be able to decide what to use client side… that said, why can’t a supertcp server handle messages send through regular tcp channel? is there some kind of marker in the data on which you stop the communication?
supertcp protocol allows to send some commands like hello, ping, etc. plain tcp channel isn’t compatible with it.
why you can use plain http for initial connection?
cause i’m lazy
and cause it would be a nice to have in the RO toolbox if the client could auto adapt to the server, the only thing needed at the client would be the ip of the server …
so all tcp channels can basically talk to each other using the default settings?
all our channel types are interchangeable, i.e. super tcp can be easily replaced with http,super http or tcp and vice versa.
the MegaDemo sample illustrate this.
each channel type has advantages and disadvantages.
so you should decide what channel is more suitable for you.
that i know, but tcp can’t talk to supertcp…
agree.
for superhttp we have made some changes for understanding plain http requests.
for supertcp we haven’t done similar changes