eladb
commented
12 years ago Agreed
-----Original Message----- From: Seth Fitzsimmons [mailto:reply@reply.github.com] Sent: Monday, February 13, 2012 11:39 PM To: Elad Ben-Israel Subject: [node-jersey] Shared sockets? (#2)
@eladb:
I don't think that packets will be mixed. Since javascript is single threaded, there is no chance for multiple messages to be written concurrently into the socket, so they will be always serialized. BTW, I don't think that this is even possible in multi-threaded systems because each message is queued into the hardware buffered and therefore they are also serialized. On the other side, you cannot guarrantee that packets will not be mixed, but you can guarantee here that no message will exceed a packet size (4KB I think) and then, you are clean on that end as well. But you know what, that might all be a premature optimization...
I was thinking that with more than 1 writer (or more than 1 writer hitting the proxy), sharing sockets would be a problem, but that presumes that the receiving socket will be shared, which will never be true. Likewise if jersey is the exposed TCP interface and older clients (using tcpudpsocket.js, which seemed to be crippled by variable packet size) are hitting it with now-invalid messages.
In short, I don't see any protocol-related hurdles to using shared sockets/connections, but I may still be missing something.
For now, I'm considering it a premature optimization, primarily due to the error conditions that need to be accounted for when connections/sockets are long-lived.
Reply to this email directly or view it on GitHub: https://github.com/mojodna/node-jersey/issues/2
@eladb:
I was thinking that with more than 1 writer (or more than 1 writer hitting the proxy), sharing sockets would be a problem, but that presumes that the receiving socket will be shared, which will never be true. Likewise if jersey is the exposed TCP interface and older clients (using
tcpudpsocket.js, which seemed to be crippled by variable packet size) are hitting it with now-invalid messages.In short, I don't see any protocol-related hurdles to using shared sockets/connections, but I may still be missing something.
For now, I'm considering it a premature optimization, primarily due to the error conditions that need to be accounted for when connections/sockets are long-lived.