import openfl.net.Socket;
var socket:Socket = new Socket();
socket.connect("127.0.0.1", 51432);
It connects to the server but crashes instantly with any incoming data. Is this even supposed to work on c++?
I believe that the socket class works in -Dlegacy, maybe give that a try, and see if it does?
If it does, then perhaps there is just a small oversight in how it was adapted to the newer codebase
I grown so tired of that openfl shit I already have made my own Socket class. The only thing I wish someone would tell me is how soon it could possibly be fixed in future?
I have not personally used sockets (I am not sure if there’s a good way to unit test them, or to test them in general?). In -Dlegacy I believe we got sockets as a contribution from a team who had them working, I copied this over to the newer code, but like I said, don’t have any tests for it.
Does your Socket class use the same API? we could look at replacing the implementation 
hi，I have the same problem，can you share your socket class with me？
Same here - working socket in legacy, no go in nextGen. Could you share your code?
You can always use sys.net.Socket for cpp/neko - that works in legacy and next alright.
+Hasufel
The point is you just use sys.net.socket for cpp target, flash.net.socket for flash e.t.c. It is basically the same thing that openFL is supposed to do. I made only flash and cpp realization and I don’t feel like I should share it because it is too raw and it has only functions which I need.
So I’m trying to do this, using sys.net.socket. Everything seems to work, as long as I do not try to read more than one line of data. However, the server I’m dealing with does exactly that, sending more the one line at times. If more than one line is sent from the server, the socket seems to lock up. Any idea what is happening here?
hak88, you might want to use threads on both sides. Maybe have a look at how StablexNet does it: https://github.com/RealyUniqueName/StablexNet
But is this the problem I’m having? No threads? I mean what I need works totally fine without any threading(as far as I can tell) in legacy. And a long as I read only a single line, there is no problem in in nextGen either. The problem appears as soon as I try to read beyond the first line or rather beyond the linefeed character.
hak88 sys.net.Socket class allows you to address original socket class for C++ and it works the same way. It can work in blocking and non-blocking modes (which could be selected with Socket.setBlocking()). Blocking mode requires an individual thread for each connected client. Non-blocking mode is more applicable for servers with large amount of clients, separately connected, and it does not need multi threading, you have to call Socket.select() function repeatedly to assort sockets with incoming/outgoing data or any new events at all, just like you do on native platforms.
public function new(port:Int, feedbackFunc:String->Void, maxConnections:UInt=100)
{
server = new sys.net.Socket();
maxConn = maxConnections;
fbFunc = feedbackFunc;
server.setBlocking(false);
server.setFastSend(true);
try
{
server.bind(new sys.net.Host(Host.localhost()), port);
}
catch (e:Dynamic)
{
trace("Bind failed on port: " + port);
return;
}
server.listen(5);
fbFunc("Listening, port " + port + " host " + Host.localhost());
allClientSockets = new Array<Socket>();
while(true)
{
if (allClients.length > 0)
{
var selectResult = Socket.select(allClientSockets, allClientSockets, null, .05);
for (w in selectResult.read)
{
var s:BaseClient = w.custom;
if (s.recv())
{
allClientSockets.remove(w);
fbFunc("Client distonnected");
}
}
}
Sys.sleep(.1);
AcceptConnectionMove();
ServerTick();
}
}
w.custom contains a link to a client class and s.recv() handles incoming data, returning true only if connection is closed or client is dropped.
in order to read binary data from socket inside recv() function I use
try
{
bytesRead = socket.input.readBytes(incomingBuffer, incomingBuffer.position, 900);
}
catch (e:Dynamic)
{
return true;
}
1 Like
Thanks for this.
I am not building a client and server, only a client. I have no control over the server, which is the webservice for a physical computing device.
Does the blocking/unblocking apply to the client side at all?
What is happening:
_socket.input.readLine() // works fine by itself
while(true){
_socket.input.readLine() // locks up if more than one line is received
}
var msgLength =_socket.input.readInt8(); //reads the whole amount of bytes as far as I can tell
var msgBytes = _socket.input.readString(msgLength); //locks up
Does that make sense?
Hey guys 
openfl.net.Socket is open for a reason, plus, the legacy version (openfl._legacy.net.Socket) is in there as well. Please feel free to suggest changes to make things more stable
EDIT: Oh, and if we read an entire message length, we should read (I assume) up to a max buffer size, and loop until we read the full message length
Yes, see my other post in the tvos thread - openfl._legacy.net.Socket works just fine, but openfl.net.Socket does not.
From what I can see, sys.net.Socket, does not read the entire buffer correctly, because when I loop, it locks up after the first linefeed.
I feel a bit stupid now - the problem was not all in openfl.net.Socket, but rather in openfl.net.XMLSocket, which was lacking a lot of code from _legacy. I put it all in and it works now.
I would sent a pull request, but it seems github does not like me right now. I’ll send a private pm with the changes
Thanks for the PM, I’ve made a few changes (for HTML5 sake) and I think this is good to go. In the future, I’d like to merge the implementation so that XMLSocket uses the Socket class on HTML5 as well, but we’ll need a good test to confirm it before making changes there
Was this the only issue? Was there another specific to the newer code?
1 Like
This was the only issue. Thanks!
Well that was easy 